Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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 5 days.

« Archives, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220

Missing executable 'shellcheck', please install

I'm on Pop OS. If I install Konsole natively or as a snap or flatpak it keeps saying 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)

There is https://chat.pop-os.org, https://www.reddit.com/r/pop_os/, https://unix.stackexchange.com/, so many options.. beef [talk] 03:25, 24 May 2025 (UTC)

Syncing user scripts from an external Git repository to Wikipedia

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 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 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)

  This. I'm concerned that having people upload a BotPassword or owner-only OAuth token was even considered, when a "normal" OAuth token is so much more obviously the way to go for that option. Anomie⚔ 13:03, 24 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)

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)

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)

Everyone that uses this sync scheme will have all development activity on GitHub 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)

If someone does choose to sync from Git to Wikipedia, then they must use the Git repo as their primary place for development. I cannot think of any case where people would have an onwiki version that is more up-to-date than the Git version, given that the idea of having it sync is based on the assumption that Git is used as the most up-to-date place. beef [talk] 03:29, 24 May 2025 (UTC)

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 time when a heavily used script broke and multiple interface admins refused to apply an unambiguous 1-line bug fix.

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 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.
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.

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).

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)

If I have to choose between two processes that can't co-exist, I'll choose the one that offers more benefits. A git-based workflow enables unit testing, transpilation, linting and better collaboration. It offers a change review interface that allows for placing comments on specific lines. As for talk page requests, refer to my comment above about how useful they are. – SD0001 (talk) 12:41, 24 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 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 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)

  The problem with this alternative approach is that it is just hard to manage.

  If I make a user script, it should be my own. Under a bot's userspace, you'd need a separate process for requesting creation and deletion.

  Also this makes it harder for pre-existing scripts to be synced. People already using and developing a script at an existing location cannot choose to adopt a Git sync. And it makes it much more harder for the person to disable syncing (compared to editing in your own userspace to remove the header). beef [talk] 03:32, 24 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)
• I know this is not going to happen, but i consider it unfortunate that we have to do all these hacks. A more reasonable approach would be if there was a spot on gerrit where script authors could put their gadget scripts (With CR excpectations being similar to on wiki instead of normal gerrit) and have them deployed with normal mediawiki deployments. I guess there's all sorts of political issues preventing that, but it seems like it would be the best approach for everyone. Gadgets deserve to be first-class citizens in the Wikimedia code ecosystem. Bawolff (talk) 18:03, 23 May 2025 (UTC)

  We're a top-10 website in the world, I wouldn't call it "political" that we could be hesitant about loading executable code from an external commercial platform in to our system without our review. — xaosflux ^Talk 23:47, 23 May 2025 (UTC)

  If the community wants to restrict the sync to only Wikimedia GitLab, there wouldn't be any objections on my part, though I don't see why we can't do GitHub as well. beef [talk] 03:37, 24 May 2025 (UTC)

  To clarify, I'm just saying, in the ideal world, gadgets would be deployed as part of MediaWiki (i.e. They would ride the deployment train). Its weird that this stuff is being layered on top. I understand that there are political & historical reasons why this is not the case, but ideally gadgets would be treated the same as any other site javascript. Alas that is not the world we are living in. Bawolff (talk) 23:55, 25 May 2025 (UTC)

  The train is slow and mediawiki developers have been known to argue with communities about practices. — xaosflux ^Talk 00:46, 26 May 2025 (UTC)

• The only concern I have is that you should require the existing interface administrators be given write access to the repository on request. Otherwise this falls into the ballpark of me not personally seeing the value or using this myself but if other people think it's useful then more power to them. * Pppery * _{it has begun...} 17:37, 25 May 2025 (UTC)
• I'm highly supportive. I hope the default for devs of major scripts will become deployments from GitHub (the current ad hoc system is honestly pretty wild). Best, KevinL (aka L235 · t · c) 23:49, 27 May 2025 (UTC)

Extended-Confirmed Restriction not showing up

I'm on the website on my phone. I'm using Brave browser, but I checked with Chrome and it's the same. Anyway, maybe this is intended, if so I apologize, but I figured there's no harm in checking. I am not an extended-confirmed user, so when I attempt to make an edit on the talk page of a contentious topic, there should be a banner that shows up and warns me not to. On my computer it does show up. But on my phone I originally couldn't find it at all. I've looked more carefully, there is a symbol ⓘ where it says "Learn more about this page". If I tap on that then I see the banner in question. That seems odd though when new users often would tap it. But maybe it's how it's supposed to work? It's also odd that when I switch to desktop mode on my phone, the banner briefly appears and then disappears. And can then no longer be seen without tapping on the aforementioned ⓘ. So that seems odd and is what pushed me to decide to write this, I apologize again if I overstepped tho. I am a pretty new user as shown by me now being extended confirmed and having to deal with this lol Ezra Fox🦊 • (talk) 22:32, 23 May 2025 (UTC)

You seem to be asking about an 'edit notice'. Can you provide an example of a page? — xaosflux ^Talk 23:42, 23 May 2025 (UTC)

I'm not sure what you mean. But it's the banner that says "Stop: You may only use this page to create an edit request". Since I'm not extended confirmed. But for me that's not automatically there, I have to press the link at the top that says "ⓘLearn more about this page". Which I usually wouldn't bother to do. So like when I first edited a talk page aboutthe "the Arab–Israeli conflict" I wasn't supposed to, but I didn't know that because I hadn't seen the banner. I'm just wondering if it's intended to not have that banner show up automatically Ezra Fox🦊 • (talk) 07:18, 24 May 2025 (UTC)

Can you provide a link to the page you are seeing this on? — xaosflux ^Talk 08:23, 24 May 2025 (UTC)

oh I mean any page that should have that banner. Like the first time it was this page:

https://en.m.wikipedia.org/wiki/Talk:Detention_of_Mahmoud_Khalil

I don't see that banner unless I click on ⓘLearn more about this page, which I don't usually think to click on. And imo most new users probably wouldn't. And so the banner would be pretty useless. And my question is if that's intended. I feel like I've been pretty clear and I'm getting frustrated repeating myself, so my apologies if I've come of as terse here. Ezra Fox🦊 • (talk) 11:02, 24 May 2025 (UTC)

• Hmm, able to replicate. I thought this was resolved way back in phab:T312587, which is why we turned off the js gadget that User:Alexis Jazz developed. AJ, was this working in mediawiki and has now regressed? — xaosflux ^Talk 00:41, 26 May 2025 (UTC)

  phab:T201595 regression even? — xaosflux ^Talk 00:43, 26 May 2025 (UTC)

  @Xaosflux Not able to replicate. There are no edit notices on the pages linked above, as far as I can see. Can you please explain more precisely what messages you expect to see (please link the template), on which pages (please link an example page) and in which place / when performing what action? Matma Rex talk 07:16, 26 May 2025 (UTC)

  OK, strike that! There are indeed no edit notices. This is the "Learn more about this page" (from DiscussionTools I believe) hiding the lede section. Mobile has decided to hide all of that behind the button - meaning that important to us templates in the lede (such as the 'Contentious topics' ones saying there are rules about editing the talk page) aren't going to be seen by mobile editors. Suppose these would need to actually be put in to edit notices if we want them seen? — xaosflux ^Talk 11:09, 26 May 2025 (UTC)

  @Matma Rex - I know you worked that a bunch, is there perhaps a class that can be added to something to make it not be absorbed in to that hidden header for talk pages? — xaosflux ^Talk 11:16, 26 May 2025 (UTC)

  (Oh, so we're talking about the "Stop: You may only use this page to create an edit request" message with a red background from Template:Contentious topics/Arab-Israeli talk notice. I could not see it because my account is extended-confirmed, which made me extra confused. This is why I asked about which template and which pages we're discussing.)

  is there perhaps a class that can be added…

  No, the hidden header just wraps the whole section, it doesn't have a way to exclude anything.

  I noticed that on some talk pages with obscenely long headers, some header information has been moved to non-header sections (e.g. Talk:Donald Trump has 4 such sections, which is also insane), but to be honest I am not sure what is the point of that, since all sections on talk pages are collapsed anyway. I guess the heading titles are a bit helpful.

  …meaning that important to us templates in the lede (such as the 'Contentious topics' ones saying there are rules about editing the talk page) aren't going to be seen by mobile editors

  Even if it wasn't hidden, I expect most people wouldn't notice it, because it's just one message in a huge list of useless junk. If this message is so important, why is it placed in the middle of the list, after an old merge notice and a huge generic talk page notice, and closely followed by a DYK notice, a content assessment by no less than 8 WikiProjects, and other stuff? That is no place to display an important message. See also discussion in #What to do about possibly excessive talk page header notices/warnings... above.

  Suppose these would need to actually be put in to edit notices if we want them seen?

  Yes, it seems to me that the edit notice would be a much better place for this message. Matma Rex talk 16:08, 26 May 2025 (UTC)

  Thanks for the info. I'll leave some notes elsewhere for people that use those templates, that others should not assume that their presence in the wikitext would make them visible to all editors - they can move them to edit notices if necessary. — xaosflux ^Talk 22:44, 26 May 2025 (UTC)

  You're right about the order of messages not being good there. We've got WP:TALKLEAD as guidance, which is not being followed here. I'll fix it tomorrow morning (~8h from now) when I'm not on mobile anymore. --rchard2scout (talk) 23:08, 26 May 2025 (UTC)

  @Xaosflux @Rchard2scout Thank you both. And I'm sorry for being cranky, I've been unhappy about the talk page banners for a long while. :) Matma Rex talk 08:58, 27 May 2025 (UTC)

  Xaosflux, sorry for the late response. If I understand the discussion above correctly, and this is also what I see on the linked page, there is a warning in the lede about having to be EC to discuss anything other than edit requests. My gadget Wikipedia:EditNoticesOnMobile and Mediawiki's native implementation of edit notices have no relation to what is in the lede.
  I agree with Matma Rex that the talk page lede banners are a bit too much sometimes, especially with stuff like ancient merge notices. — Alexis Jazz (talk or ping me) 10:55, 28 May 2025 (UTC)

  Thank you for the reply, yes my initial misdiagnosis that the OP was asking about an edit notice, but this wasn't an edit notice. — xaosflux ^Talk 12:38, 28 May 2025 (UTC)

For the record, non-EC actors are allowed to edit talk pages. They are restricted to edit requests if there are EC restrictions in place (with or without page protection). My understanding is that users on smartphones have never been shown a warning for talk pages regardless of the protection status of the article. Sean.hoyland (talk) 10:16, 26 May 2025 (UTC)

Now that we see this is by design (the entire lede section of talk pages is hidden by discussion tools) - potential options for this specific template can be discussed further at Template_talk:Contentious_topics#mobile_notice. — xaosflux ^Talk 23:27, 26 May 2025 (UTC)

Database error

Editing Iran, got:

Database error To avoid creating high replication lag, this transaction was aborted because the write duration (4.789069890976) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead. [ad93a55c-9cb6-4d73-8210-931e35864660] 2025-05-24 19:05:40: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

I was adding a single source to the Bibliography, so it is moronic to be told to do multiple smaller operation. DuncanHill (talk) 19:07, 24 May 2025 (UTC)

The only fix to the problem described that anyone on wiki has any power to enact is to reduce the size of the page. 420kb is obscene.

And one would probably be told, were one to report it to Phabricator, to reduce the size of the page, for the same reason. Izno (talk) 21:40, 24 May 2025 (UTC)

It was a lock timeout while getting an exclusive lock for updating the page (Specifically on page_latest field of page table). Most likely has very little to do with the page size (The locks should not be held during page parsing). Possibly the DB servers just happened to be overloaded at the exact time you were making that edit, or possibly a bunch of people were trying to edit the page at the exact same time while things were being slow. The error message is a generic one, and is reasonably good generic advice for that error in the average case, but as there can be a lot of causes for this type of error, its sometimes not appropriate advice. Bawolff (talk) 20:26, 27 May 2025 (UTC)

Actually, maybe I spoke too soon. It looks like what happened is at May 24, 2025 @ 19:05:39.361 there was an API edit that held the write transaction for 8.3 seconds (during which time nobody could edit the article). Parsing Iran takes almost exactly 8.3 seconds so its likely that is what was happening during that transaction. At May 24, 2025 @ 19:05:40.436 your edit was cancelled because it was waiting for the other edit to complete for more than 3 seconds. So it does seem like it was related to how complex that page is. I'm surprised that DB locks are being held during parsing. That seems surprising to me, but perhaps I just don't know enough about the internals of the edit process and that is an expected thing. Bawolff (talk) 20:45, 27 May 2025 (UTC)

Holding a lock through parsing would be surprising to me too. Maybe related to transcluded content needing to be a single version? Best I can think of for a rationale. Izno (talk) 20:51, 27 May 2025 (UTC)

The extra weird part is it looks like it parses the page twice. The sequence of logs looks as follow (This is for this edit):

• May 24, 2025 @ 19:05:21.896 - StashEdit determines that there is no cached stash edit (This is expected because the edit is coming from a JS script)
• May 24, 2025 @ 19:05:30.792 - Parsing Iran was slow, took 8.82 seconds
• May 24, 2025 @ 19:05:39.106 - Parsing Iran was slow, took 8.03 seconds
• May 24, 2025 @ 19:05:39.361 - Suboptimal write transaction ended - 8.321 seconds (Almost all of which spent outside of DB operations). John Warhammer's edit is saved.
• May 24, 2025 @ 19:05:40.436 - DuncanHill's edit is aborted after waiting for locks for 4.789 seconds and 1.074 seconds of other (php) delay.

So presumably the API is trying to parse the page prior to starting the transaction, but for some reason is failing to use that parse during the transaction. The other weird thing is it looks like Duncan's edit is only really aborted after it gets a lock, in which case the rest of the write process would presumably be quick, so that is a little unfortunate. i guess it checks if the write transaction is taking too long only at the step of doing the next write action. Bawolff (talk) 21:06, 27 May 2025 (UTC)

Quarry queries

Tracked in Phabricator
Task T395201

Hey, all,

I run queries on Quarry and right now I'm getting the message:

• Error
• This web service cannot be reached. Please contact a maintainer of this project.
• Maintainers can find troubleshooting instructions from our documentation on Wikitech.
• proxy-5.project-proxy.eqiad1.wikimedia.cloud

It says this for all of the queries I run and just trying to view the directory page of recent queries. Any idea what the problem is and when it might be fixed? Liz ^{Read! Talk!} 04:38, 25 May 2025 (UTC)

It is back up, and the nerds are investigating what happened in the Phab ticket. Polygnotus (talk) 09:31, 25 May 2025 (UTC)

"Page Size" and "Who Wrote That?" tools not working on James Cook article

I frequently use the WP:Prosesize gadget (aka Page Size tool) and the WP:Who_Wrote_That? tool from my tool menu (the page size tool required enabling a gadget in my Preferences; the latter tool required installing a JS script). I've used both tools on many articles.

Neither tool works on the James Cook article. I don't think the issue is my computer, because I've tried the tools on several computers, and they don't work on any computer. The problem is only with that one article.

Strangely, the tools seem to work for the James Cook article when I am not logged in. They only fail on that article when I am logged in. Again, the tools work on every article except the James Cook article.

Can someone try the WP:Prosesize tool on James Cook and see if it works for them. Also, try the Who Wrote That? tool if you have it. If it fails for you: can anyone suggest a change to James Cook article to get the tools working? Noleander (talk) 05:49, 25 May 2025 (UTC)

@Noleander Someone asked a similar question and it resulted in User:Polygnotus/Scripts/ProseSize.js. Let me know if you have any feature requests/bug reports. Polygnotus (talk) 06:24, 25 May 2025 (UTC)

Thanks for the reply. I don't fully understand what that linked script is. Is it an alternative version of the prose size tool? or is that the original prose size tool, with a bug fix?

And I assume that linked script is not a solution for the Who Wrote that issue, correct? Noleander (talk) 06:31, 25 May 2025 (UTC)

@Noleander Is it an alternative version of the prose size tool? Indeed.

I assume that linked script is not a solution for the Who Wrote that issue, correct? Indeed. Polygnotus (talk) 06:34, 25 May 2025 (UTC)

If you add importScript('User:Polygnotus/Scripts/ProseSize.js'); to User:Noleander/common.js it should work. It adds a "calculate prose size" option to the bottom of the Tools menu. Polygnotus (talk) 06:36, 25 May 2025 (UTC)

Ah, okay, thanks for the clarification. If I can find some time to download the script, I'll try it out soon. Thanks! Noleander (talk) 14:19, 25 May 2025 (UTC)

I don't know whether this helps to narrow down the cause of the Who Wrote That issue, but I have code that relies on the API at wikiwho.wmcloud.org and the API seems to work fine for the James Cook article. Sean.hoyland (talk) 06:47, 25 May 2025 (UTC)

@Sean.hoyland Thanks ... Interesting data point. I probably won't spend any more time on this since I found a workaround (namely: the Who Wrote That? tool works on the JC article when I am logged out of WP).

Do you know if the Who Wrote That? tool has a bug reporting system? Maybe I can submit a bug report to the developer of WWT? before I move on to other things. Noleander (talk) 14:22, 25 May 2025 (UTC)

I'm guessing this edit fixed it. I have seen stray and misplaced curly brackets messing up the browser extension before. I'm not sure where bug reports go. Maybe here might work. The issue tracker is here. Sean.hoyland (talk) 14:45, 25 May 2025 (UTC)

BetterSleep article in main namespace showing unexpected noindex meta tag despite resolved notability

Hello,

The article BetterSleep was initially flagged for notability concerns, but these have been thoroughly addressed and resolved through discussions on the talk page. The article was subsequently accepted for publication in the main namespace. However, when viewing the page source, the following meta tag is present:

<meta name="robots" content="noindex,nofollow,max-image-preview:standard">

This tag instructs search engines not to index the page or follow its links, which prevents the article from appearing in Google and other search results.

I am unable to remove the notability or noindex templates myself, as this appears to be controlled by page protection or administrative restrictions. Additionally, I have purged the page cache using ?action=purge, but the noindex tag remains.

Could this be a caching issue, leftover from previous templates, or an internal misconfiguration on the server side? Your assistance in resolving this so the article can be properly indexed would be greatly appreciated.

Thank you! Боки 💬 📝 16:51, 25 May 2025 (UTC)

Wikipedia:Controlling_search_engine_indexing#Indexing_of_articles_("mainspace") Articles younger than 90 days are not indexed, unless they have been patrolled Polygnotus (talk) 17:21, 25 May 2025 (UTC)

Also you really need some refs that demonstrate notability because I doubt this would survive AfD. Polygnotus (talk) 17:32, 25 May 2025 (UTC)

WikiWix.com

https://wikiwix.com is a small web archive provider based in France. They have links in 4,585 articles on Enwiki. Most of are irreplaceable ie. there are no replacements at Wayback or Archive.today - as far as I can tell, the site has been broken fully or partly, continually or intermittently. If you go to frwiki and look at the references section for any article (Example)), every link has a superscript "[archive]" tag; this is done automatically via a MediaWiki plugin. URLs can take different forms for example:

• https://archive.wikiwix.com/cache/20110224124311/https:/whc.unesco.org/en/list/91 .. the inclusion of the 14-digit timestamp was a requirement before they could add links to Enwiki. However they often generated fake timestamps.
• https://archive.wikiwix.com/cache/?url=https:///whc.unesco.org/en/list/91 .. this is the native form on Frwiki, they don't use timestamps

Neither of the above are working (for me). The main homepage is confusing how it works. I'm looking for help to understand this site, the situation, or any information. -- GreenC 16:54, 26 May 2025 (UTC)

Most of are irreplaceable How accurate is that statement? Since https://whc.unesco.org/en/list/91 is still active, it can simply be archived now, if the source content hasn't changed. Nobody (talk) 13:08, 27 May 2025 (UTC)

Tech News: 2025-22

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• A community-wide discussion about a very delicate issue for the development of Abstract Wikipedia is now open on Meta: where to store the abstract content that will be developed through functions from Wikifunctions and data from Wikidata. The discussion is open until June 12 at Abstract Wikipedia/Location of Abstract Content, and every opinion is welcomed. The decision will be made and communicated after the consultation period by the Foundation.

Updates for editors

• Since last week, on all wikis except the largest 20, people using the mobile visual editor will have additional tools in the menu bar, accessed using the new + toolbar button. To start, the new menu will include options to add: citations, hieroglyphs, and code blocks. Deployment to the remaining wikis is scheduled to happen in June.
• The #ifexist parser function will no longer register a link to its target page. This will improve the usefulness of Special:WantedPages, which will eventually only list pages that are the target of an actual red link. This change will happen gradually as the source pages are updated. [1]
• This week, the Moderator Tools team will launch a new filter to Recent Changes, starting at Indonesian Wikipedia. This new filter highlights edits that are likely to be reverted. The goal is to help Recent Changes patrollers identify potentially problematic edits. Other wikis will benefit from this filter in the future.
• Upon clicking an empty search bar, logged-out users will see suggestions of articles for further reading. The feature will be available on both desktop and mobile. Readers of Catalan, Hebrew, and Italian Wikipedias and some sister projects will receive the change between May 21 and mid-June. Readers of other wikis will receive the change later. The goal is to encourage users to read the wikis more. Learn more.
• Some users of the Wikipedia Android app can use a new feature for readers, WikiGames, a daily trivia game based on real historical events. The release has started as an A/B test, available to 50% of users in the following languages: English, French, Portuguese, Russian, Spanish, Arabic, Chinese, and Turkish.
• The Newsletter extension that is available on MediaWiki.org allows the creation of various newsletters for global users. The extension can now publish new issues as section links on an existing page, instead of requiring a new page for each issue. [2]
• View all 32 community-submitted tasks that were resolved last week.

Updates for technical contributors

• The previously deprecated ipblocks views in Wiki Replicas will be removed in the beginning of June. Users are encouraged to query the new block and block_target views instead.
• Detailed code updates later this week: MediaWiki

Meetings and events

• Wikidata and Sister Projects is a multi-day online event that will focus on how Wikidata is integrated to Wikipedia and the other Wikimedia projects. The event runs from May 29 – June 1. You can read the Program schedule and register.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 20:01, 26 May 2025 (UTC)

Is the new filter to Recent Changes supposed to replace ORES? Nardog (talk) 03:41, 28 May 2025 (UTC)

@Nardog Per wikitech:ORES#Model_deprecation they are deprecating the ORES goodfaith/damaging/reverted models and intend to replace them with a new Revert Risk model. Unfortunately, the Language Agnostic Revert Risk model that they are deploying in the above item is not as good at catching vandalism in English as the existing ORES ones, and the Multilingual Revert Risk model that does have parity in English is currently too slow. --Ahecht (TALK
PAGE) 13:32, 28 May 2025 (UTC)

{{See also}} not accepting in-page section links

{{see also|#Tech News: 2025-22}}

results in

[quote begin]

See also: § Tech News: 2025-22

[quote end]

with warning "no output: none of the target pages exist." I assume Module:Labelled list hatnote needs to be fixed somehow. Nardog (talk) 09:26, 28 May 2025 (UTC)

{{See also}} was changed in December per Wikipedia:Templates for discussion/Log/2024 December 13#Template:See also if exists to check if the link exists. I have just updated it so that you can turn this off by setting |ifexists=false, but I agree that detecting anchors should be done automatically by the module. --Ahecht (TALK
PAGE) 13:39, 28 May 2025 (UTC)

I went ahead and updated the module as well so |ifexists=false shouldn't be necessary for section anchors. --Ahecht (TALK
PAGE) 18:19, 28 May 2025 (UTC)

@Ahecht: Thank you for making this correction! This is quite helpful to have fixed now 🙂 Cheers! Johnson524 20:54, 28 May 2025 (UTC)

Cite constitution toggle request

Hello! I would really appreciate it if anyone could add a parameter to the Template:Cite constitution to toggle the "|polity" parameter, which as of now automatically wikilinks any value imputed. For context, I'm trying to cite the constitution of "the National FFA Organization", but a wikilink to the "Constitution of the National FFA Organization" not only does not exist and is not helpful, but likely never will. Being able to turn off this auto-linking if one desires would be very useful for this and other non-governmental constitutions. Cheers! Johnson524 20:53, 28 May 2025 (UTC)

Mobile menu question

I would like to propose a change to the mobile menu sidebar on the top left to add a link. If I get a consensus to add a link there, can interface administrators implement it? Interstellarity (talk) 00:28, 29 May 2025 (UTC)

No. Izno (talk) 00:29, 29 May 2025 (UTC)

To expand, you would need to follow the process discussed at phab:T65459#10833022. Izno (talk) 00:32, 29 May 2025 (UTC)

Edit Source

Currently, you can edit the entire article only .

I suggest making a mechanism that will track individual paragraphs and display a PENCIL "Edit Source" on the right.

You can see something similar in many web-mails (gmail.com).

Of course, the question immediately becomes what to consider a paragraph. This is not so important, you can combine several paragraphs to a large one.

It's better than editing the entire article on 4 screens. Seregadu (talk) 04:40, 29 May 2025 (UTC)

Check out Wikipedia:MiniEdit. Remsense ‥ 论 04:44, 29 May 2025 (UTC)

Yes, that's exactly what I'm talking about. It often happens that the user does not see some scripts on the page. I've disabled everything I can.  And on Chromium 136, I don't see this pencil. Like 99% of Wiki users Seregadu (talk) 04:56, 29 May 2025 (UTC)

I'm not exactly sure what issue you're having, but this is a script you need to add! I don't think you've done that, at least not to User:Seregadu/common.js, which is where you would only have to copy one line to enable MiniEdit. If you need more help, don't hesitate to ask. Remsense ‥ 论 04:59, 29 May 2025 (UTC)

I'm going to try adding a script now, but why not do it for everyone?

This script only works on the user's side and does not create a load on the Wiki. Thanks for the script ! ). Seregadu (talk) 05:01, 29 May 2025 (UTC)

Glad if I could help! Honestly, it's always worth considering that most people aren't "power users" like you and I, and maybe you can imagine little symbols showing up all the time being confusing or stressful for someone's grandma or a young child. Remsense ‥ 论 05:03, 29 May 2025 (UTC)

This script edits only 1 level. Very sadly. Most discussions have 4 pages that are far from level 1. Seregadu (talk) 05:10, 29 May 2025 (UTC)

Because the mechanism used to edit something is the section, not the paragraph. When you click an edit button next to a paragraph and get the whole section, your user will be like "what happened?!"

And, to be honest, a button every paragraph would be a lot of clutter. Izno (talk) 05:10, 29 May 2025 (UTC)

No! Exactly every paragraph ! After all, the pencil is already there and it works well. In this conversation, I can edit only the first 5 lines. Let's wait for your opinion when this conversation grows to 4 screens. Seregadu (talk) 05:14, 29 May 2025 (UTC)

2 problem that , that I found right now! And where is the community see ? I'm not just adding empty lines, I'm testing the script. I see that it requires updating the browser cache after each text change. It's not normal. it's as if adding text removes the script from the browser cache. Seregadu (talk) 05:20, 29 May 2025 (UTC)