Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

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, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224

Image Browsing on Mobile

Hi everyone,

The Reader Growth team is starting work on an experiment to test how to make it easier for readers, particularly visual learners, to browse and discover images and other multimedia on Wikipedia articles.

We're working on this because of our goal to help new readers find Wikipedia useful and engaging (here in the annual plan), and Community Wishlist requests for improved discovery of media.

Why is this message so long?

Since the Simple Summaries experiment conversations, we’ve been reflecting on how we can better come up with, discuss, and work together on reader-focused work. The Product and Technology Advisory Council (PTAC) talked about this and they made some recommendations for how to improve. If you get a chance, please check out this page where we talk through the changes we plan on making and leave any feedback on the overall process. You’ll see us putting these recommendations into action for this and future projects.  

Why are we working on this?

Wikimedia’s mission is to make knowledge accessible to every human on the planet, which means continuing to figure out how Wikipedia can be useful to new people just starting to visit it. Unfortunately, our recent data shows that over time, a significantly smaller percentage of internet users are visiting Wikipedia and relying on it as their primary source of knowledge, even as internet usage worldwide increases. To address this, we want to experiment with ways that help new generations of readers find Wikipedia useful, return frequently, and eventually become the editors we need to keep the projects healthy.

Many of these new readers are visual learners who rely on images and multimedia to learn; in surveys of global internet users that WMF conducts periodically, “more images/photos” is the most asked-for improvement to Wikipedia (slide 53). While other platforms have adapted to the shift toward visual learning, Wikipedia has vast amounts of visual content that could be made easier for readers to see. Making it easier to explore the images that are already in Wikipedia articles could make learning on Wikipedia more engaging and encourage new readers to come back more frequently, with some of them eventually becoming the editors of the future.

What idea are we testing?

We want to try out ways for readers who are most interested in images to see and navigate them directly, without distracting from the text of the article.  

What stage is this project in?

Right now, this project is in Phase 0 / Phase 1 (exploration and early experiment design). That means nothing is being launched yet. We are gathering input and sharing early designs to help shape an upcoming small-scale A/B test, in which we’ll decide whether the idea is worth any further investment.

What is the timeline?

We want to spend September and October discussing the idea and building a simple version of a new image discovery feature. Then, we hope to A/B test this version with a small group of readers (about 0.1%) starting in late October and ending four weeks later. We’ll measure whether people engage with the feature and whether they visit Wikipedia more often. If we see positive results, in November and December, we’ll share the results of this A/B test and decide together whether to proceed and what changes to make if we do.

What does the experiment include?

We are designing the experiment to give us data on the following ideas for this feature:

• A more intuitive way to begin looking at the images in an article on the mobile website
• Easier connection from images back to the text – an easy way for readers to go between looking at the image and looking at where the image is in the article
• Simplified exploration of more images – allowing readers to see images for the same article for other wikis if interested

Our current thinking for the A/B test is to build an early version of the feature for the mobile website and show it to 0.1% of all readers that explores the ideas above. We will also provide a url parameter that will allow communities to directly see the feature and provide feedback as well.  

This feature would include a gallery at the top of articles showing all the images from the article. Tapping on any image would open a browsing experience with more details, the image caption, and options to view it on Commons (if available). Readers would also be able to switch back to where the image appears within the article. At the bottom of this experience, readers will be able to view images selected by editors for the same article in other Wikipedias. Since this work is still experimental, we expect to refine and adjust this idea based on your feedback.  

Mock-ups:

This feature hasn’t been built yet, so this is a mock up of how it might work, shown in an animated gif.

https://commons.wikimedia.org/wiki/File:New_images_flow.gif

What input are we looking for from you?

1. We’re interested in showing images from other Wikipedias and Wikidata which editors have chosen for the same article on those wikis. For example, on smaller projects, this will allow them to see images from larger wikis, such as English Wikipedia, without switching wikis. In what ways might this feature change how readers interact with images in an article? How do you think these images could appear within the experience?
2. We know that some articles contain sensitive images, and it might worsen the reader experience if those images are given greater prominence. How do you think we should approach sensitive images? In initial conversations with communities on Discord, community members suggested using the notpageimage class for exclusion, as well as respecting any other exclusions Mediaviewer has. Thoughts on this?
3. We know editors have thought carefully about image placement on articles, including which feature most prominently at the top of the page. How can we make sure that any feature that raises the prominence of images doesn’t alter the integrity of the article as the editors made it?
4. Any other thoughts around the project or the mock-ups above? What are other aspects of images and image browsing that you think a brand new Wikipedia reader might find useful? Are there other pieces of this project from a contributor perspective that you think we should be aware of?

For more info on our research, mock-ups, and other details, see our project page.

Thank you! EBlackorby-WMF (talk) 16:18, 29 September 2025 (UTC)

Re item 1 above, if editors are encouraged to add images to articles, I suspect that we will see more violations of WP:NFCCP and of WP:NFLISTS, especially if that policy and that guideline are not enforced at other Wikipedias. And re item 3, we already have links to images on Commons from the bottom of many articles; maybe the {{Commons category-inline}} template and its siblings could be enhanced to actually show images rather than just link to them. Showing images from other Wikipedias without checking their licensing will probably lead to copyright issues. – Jonesey95 (talk) 17:49, 29 September 2025 (UTC)

Thanks for leaving us your thoughts, @Jonesey95! I like your idea about showing Commons images directly, I'll bring it up with the team. For this version, we held off on pulling images directly from Commons since we assumed not all of them would be immediately relevant to the article (or at least as relevant as an image selected for the same article on another wiki), but it’s definitely something we could rethink as we move forward. From your perspective, do you think those Commons images would generally be relevant/interesting to explore through in this context? In terms of licensing, thanks for the reminder - we'll definitely pull in some of the legal team to make sure there isn't anything we're missing on that front. OVasileva (WMF) (talk) 08:26, 30 September 2025 (UTC)

I don't know if the Commons images would be relevant. It sounds like you are willing to experiment, though. I do notice that Frank Lloyd Wright has an automatic link to "Wikimedia Commons" that goes to commons:Frank Lloyd Wright, which "is a gallery page containing specially selected image and media files. They have been chosen as highlights of a particular topic, but do not represent the full range of files that are available on Commons". The "Wikimedia Commons has media related to Frank Lloyd Wright" link at the bottom of the page goes to commons:Category:Frank Lloyd Wright, which is kind of a mess. It looks like the former, which is curated, might be a good choice. Using images from other Wikipedias rather than Commons seems quite likely to cause copyright issues here on the English Wikipedia. – Jonesey95 (talk) 11:11, 30 September 2025 (UTC)

If the premise is to target "visual learners", you should read Visual learning#Lack of evidence. --Ahecht (TALK
PAGE) 18:31, 29 September 2025 (UTC)

@Ahecht I think visual learning is a misnomer in this context, I think the team is planning on targeting trends where we see a lot of visitors gravitate towards visual media. Sohom (talk) 22:01, 29 September 2025 (UTC)

How will this cope with cross project image vandalism? If adding an image in one project then gets in shown on another project, this seems like a likely vector to inject image vandalism. Small projects may pack lack the resources to deal with such issues in a timely manner. Also how would a project go about excluding images it thinks are inappropriate, or is this simply forcing image choice on them? -- LCU ActivelyDisinterested «@» °∆t° 20:54, 29 September 2025 (UTC)

@ActivelyDisinterested, Regarding the two point I think the team recognizes this as a challenge and wants ideas on how this can be mitigated! Sohom (talk) 22:04, 29 September 2025 (UTC)

Yes, like @Sohom Datta mentioned, this is definitely something we’d want to build out and discuss further! @ActivelyDisinterested, I'm curious if you have any thoughts and ideas on this specifically? Right now, we plan on respecting editor choices to not include images in MediaViewer, so those already wouldn't appear in the carousel. That said, those choices would come from the wiki where the image is originally from, not the one displaying it, which doesn't fully cover your concern. We’d also explicitly mark where the image is coming from (by adding “from X Wikipedia” under the image) to set the expectation for readers that the decision to include it wasn't made locally.

Another idea we’ve floated is to make this section be opt-in only by adding some explicit “see images from other Wikis” button or link that give people the decision on whether to see these images or not. Or, we could have some sort of direct way for editors to remove an image they find inappropriate. Curious if you have other thoughts/ideas on this! OVasileva (WMF) (talk) 08:36, 30 September 2025 (UTC)

I would suggest this is optin. My concern is that the burden of patrolling images for wikis with small user bases is going to be unsustainable. Even for English Wikipedia patrolling this will be problematic, having editors from one wiki going to another wiki to correct vandalism is problematic especially when it's a much larger wiki enforcing policy on a smaller wiki. -- LCU ActivelyDisinterested «@» °∆t° 15:01, 1 October 2025 (UTC)

@ActivelyDisinterested "pack the resources " --> "lack the resources", I presume? David10244 (talk) 00:18, 3 October 2025 (UTC)

Thanks for spotting that, corrected now. -- LCU ActivelyDisinterested «@» °∆t° 00:20, 3 October 2025 (UTC)

Generally, the it is weird to read about visual learning etc. without acknowledgement that this site is designed to replicate an encyclopaedia. That is, it is designed with a particular mode of learning in mind. We should experiment with new ideas, but changing the premise of the project to attract new editors to that new premise does not help the original premise. That said, on the experiment, Re question 1, this seems likely a risky idea for other wikis to en.wiki given how much discussion there can sometimes be on ensuring that our images are useful and neutral. Philosophically this takes editorial decisions out of en.wiki and into projects en.wiki has no control over. Re question 2, neither en.wiki nor Commons has ever found consensus to or even a practical way to generate effective image filters, it seems unlikely to be worth the effort to invent a new class that somehow editors will need to decide to apply for images that are selected because they appear in the article anyway. Re question 3, it would have to be made clear that the image wheel is not part of the article. I'm not sure if the current mockup does this, as it looks like the image gallery replaces the lead image and/or infobox. Re question 4, I am not sure why a brand new user would want to go to the Commons page. Commons pages look like slightly different versions of other wiki file pages, and I'm not sure readers would want to be on our file pages either. If this wants to be useful, better to directly show relevant Commons categories that can be clicked through to. CMD (talk) 02:49, 30 September 2025 (UTC)

CMD, I wonder if it would be more in the goal of the project to surface "related images" (like say parts of a diagram or the skyline of a city) to draw users to those specific parts of the content. I'm pretty sure what is being built here is a abridged version of mediaviewer that does not immediately channel folks into commons. Wrt to your point of there never having been consensus about hiding specific images, I'm pretty sure there are existing mechanisms inside mw:Extension:PageImage that are already used to keep non-free images out of image previews, I think the team is hinting at using something similar (or even community heuristics like looking at the licensing data) to pick appropriate images. Sohom (talk) 04:24, 30 September 2025 (UTC)

I think they want the upper gallery images (is there a shorter name? wheel images?) to link to specific points in the article, which makes it like a second ToC. The Commons part is a response to "Tapping on any image would open a browsing experience with more details, the image caption, and options to view it on Commons (if available)". Hiding images by licence is possible, but I have significant doubt "sensitive images" refers to licences. CMD (talk) 04:43, 30 September 2025 (UTC)

Carousel maybe (but this doesn't fit that description since it is static)? It doesn't sound like a half bad idea to have a more visual way of navigatingsections through images (especially if the text appears below the image once the image is clicked on). Honestly, it might pique peeps curiosity about content further down in the article.

With respect to sensitive images I think the developers were talking about re-purposing features like mw:Extension:PageImages#Can_I_exclude_certain_page_images? where a CSS class prevents a image from appearing as a page image in the preview. I'm honestly not sure how widely it is used but something like that could help editors curate against specific images (if there is a local consensus on a page to not include a particular image). From what I remember, the initial proposal didn't have a "sensitive image" rider, it was added after there was feedback on discord that such a mechanism would be needed in some cases. Sohom (talk) 05:03, 30 September 2025 (UTC)

There are existing mechanisms for individual accounts to block specific images in articles, I assume such functionality would be replicated for the static carousel. However, any attempt to create a wiki-wide list of images is based on past experience not going to gain consensus here or on Commons. I don't know much about other wikis, but it seems reasonable for the developers to be aware of what the effort invested into such a tool is likely to go unused here. CMD (talk) 12:55, 30 September 2025 (UTC)

@Sohom Datta Users can opt to hide images of Mohammed; I predict that's what is meant by "sensitive images". David10244 (talk) 00:21, 3 October 2025 (UTC)

That gif file of adding essentially a scrolling gallery to an article is probably against Manual of style. I do not see it becoming used.

I have the following ideas:

1. Change Wikimedia commons link in sidebar to "Wikimedia Commons (multimedia)". It is not obvious to newcomers that it hosts multimedia content.
2. Add a read section link to every section in every article. We allready have mw:Extension:Phonos which can read text. This is mainly for people with perfectly fine vision that would like an audio version, for example they might be multitasking. Blind or half blind people just use screen readers, this feature is not useful to them.
3. Auto generate slideshows of pictures and audio. It would read an article section with mw:Extension:Phonos and switch out images as they appear in the text. I write slideshow, not video, because the rendering time alone of the video would become a hardware issue.

Snævar (talk) 03:23, 30 September 2025 (UTC)

This feature would include a gallery at the top of articles showing all the images from the article - these will include alt-text, right? Sapphaline (talk) 07:09, 30 September 2025 (UTC)

Hi @Sapphaline - thanks for the question! Yes, we'll be including alt-text for the images. OVasileva (WMF) (talk) 14:32, 30 September 2025 (UTC)

I see this as a legitimate way to improve the description and classification of images on Commons and I support this initiative.

However, I would suggest that there be a dedicated markup, be it template or lua based, or something similar for editors on the local projects to determine what images to display on each article, or not display images at all. Not all content in a Commons category may be suitable to be displayed, and neither all pages have a corresponding Commons category defined or attached in its Wikidata item. This also gives the local editors editorial control over the visual content in a similar manner as the text content here. We have had discussions that would disallow the display of certain media (Talk:Killing_of_Iryna_Zarutska#Add_a_photo_of_Iryna_Zarutska) or even to the point of deleting them, i.e. c:Commons:Deletion requests/File:Killing of Iryna Zarutska (cropped).webm.

And maybe for a start, having this feature as an opt-in feature and allow editors to organically update the articles with the images. – robertsky (talk) 06:11, 6 October 2025 (UTC)

I see no benefit to enwiki at all from this idea.

"This feature would include a gallery at the top of articles showing all the images from the article. Tapping on any image would open a browsing experience with more details, the image caption, and options to view it on Commons (if available). Readers would also be able to switch back to where the image appears within the article. At the bottom of this experience, readers will be able to view images selected by editors for the same article in other Wikipedias."

Why? Images are often placed at a particular position for a very good reason, and without that context make not much sense at the top. At other articles it would be an endless list with no purpose (List of flags of the United States). Showing images from other languages has potentially serious problems, as was already mentioned, starting with vandalism, but also e.g. showing images of Muhammad or violence or sex on languages which have chosen not to do so. But tagging which images may be problematic is a perennial proposal which gets rightly rejected every single time as unwanted by many and not practically feasible by most.

In general, the proposal creates a very distracting slideshow at or near the top of the article, taking the attention away from the encyclopedic content, and creates a kind of incomplete, random table of contents. What the actual benefit is remains very unclear. Fram (talk) 10:09, 9 October 2025 (UTC)

Wikipedia word list

I would like to generate a list of most common words in Wikipedia, and I envision saving it at Wikipedia:List of most common words in Wikipedia. Feel free to suggest to other names. I envision the article having two sections. The first section is a list of about 22 words that are in the majority of Wikipedia articles: a, all, an, and, as, at.... The second is a list of a few hundred words that aren't in the first list and are used in about 400,000 or more articles. I haven't decided where to draw the line. The position of the line might depend on how complete and accurate I believe the list is.

My immediate purpose is to assist users including myself in bifurcating regex searches that time out. Words that are used in a lot of articles (but not almost all articles) are good words to use for including or excluding along with the primary regex search to help make the regex search complete in the allotted time.

Since the purpose is to assist searching, of course my definition of "word" is whatever the search treats as a word. The words { do, does, doing } have the same or nearly the same number of results, so they count as one word (do), but { did } has a different result, so it's a separate word.

I've been generating the list from Most common words in English, Dolch Word List, and my own imagination, searching for each word in the Article namespace only and recording the count. But every time I think I'm almost done, I think of a new class of words that turn out to be common in Wikipedia. So far, I have 330 words (other than the top 22) found in more than 400,000 articles, and there's no end in sight. Is there a way to automatically generate a list of words used in the most English Wikipedia articles ? —Anomalocaris (talk) 03:53, 6 October 2025 (UTC)

@Anomalocaris sounds like you can try parsing through the database dumps at Wikipedia:Database download and generate the list(s). – robertsky (talk) 06:17, 6 October 2025 (UTC)

Robertsky: Thank you for the suggestion. I want a clean solution within Wikipedia, not a massive database download followed by SQL. —Anomalocaris (talk) 07:10, 6 October 2025 (UTC)

Unfortunately, I doubt Mediawiki is built for such a use case as it will take up server resources, be it CPU or storage. – robertsky (talk) 07:30, 6 October 2025 (UTC)

You'll need a database download (not all that massive) but no SQL. You can just strip off the headers and parse the (decompressed) file directly, splitting and counting whatever you define as a word. Perl or a similar language is ideal. Even if you're counting the number of articles with a word, rather than the total number of occurrences, then you'll probably end up with something close to the common word list plus a few specialised terms such as "References". You may want to fold the text to lower case, remove templates and possibly remove categories. Certes (talk) 09:39, 6 October 2025 (UTC)

Instead of reinventing the wheel, I'd suggest using existing NLP libraries (eg. nltk in python) that implement stopword removal, stemming and lemmatization. – SD0001 (talk) 13:28, 6 October 2025 (UTC)

There's wikt:Wiktionary:Frequency lists/English/Wikipedia (2016). Is that suitable for this purpose? the wub "?!" 09:57, 6 October 2025 (UTC)

Or just found https://github.com/IlyaSemenov/wikipedia-word-frequency/blob/master/results/enwiki-2023-04-13.txt which is in plaintext and more up to date. the wub "?!" 10:00, 6 October 2025 (UTC)

the wub: Thank you, this is very helpful. I need a list of frequent words with the frequency count, and I can start with the Wiktionary list and create the frequency count myself. I don't need to go past a few hundred words, so it's manageable. As for GitHub, the page displays "(Sorry about that, but we can’t show files that are this big right now.)" Is that message always going to be there, or if I keep trying will I ever see the file? —Anomalocaris (talk) 03:17, 7 October 2025 (UTC)

There's a "view raw" link immediately above that message, which shows you the data. —Cryptic 03:32, 7 October 2025 (UTC)

Cryptic: That's it exactly! Thank you very much, and also to the wub for posting the link in the first place.

... Well, actually, the GitHub page needs work also. It claims that the word "the" appears on 186,631,452 different pages, which is about three times the total number of pages in Wikipedia in all namespaces combined. I can use it as a word list but I need to get the page counts another way. —Anomalocaris (talk) 16:20, 7 October 2025 (UTC)

It occurs that many times, not on that many pages. – SD0001 (talk) 16:56, 7 October 2025 (UTC)

Tech News: 2025-41

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

• Paste Check is a new Edit Check feature to help avoid and fight copyright violations. When editors paste text into an article, Paste Check prompts them to confirm the origin and licensing of the content. Starting Wednesday, 8 October, 22 wikis will test Paste Check. Paste Check will help new volunteers understand and follow the policies and guidelines necessary to make constructive contributions to Wikipedia projects.

Updates for editors

• Mobile devices will receive mobile articles directly on the standard domain (like en.wikipedia.org), instead of via a redirect to an "m" domain (like en.m.wikipedia.org). This change improves performance. This week it will be enabled on Wikipedias. The existing mobile URLs and the "Desktop view" opt-out remain available. Learn more. [1]
• New date filters, creationdate: and lasteditdate:, are now available in the wiki search engine. This allows users to filter search results by a page's first or last revision date. The filters support comparison operators (e.g. >2024) and relative dates (e.g. today-1d), making it easier to find recently updated content or pages within specific age ranges. [2]
• Wikifunctions now supports rich text in embedded calls across the 150 wikis where it's enabled. To showcase this, the team created a Latin declination table that Wiktionary editors can use to automatically generate noun forms, producing clear, formatted results — see an example output. If you need any help or have any feedback, please contact the Wikifunctions Team. [3]
• An edit link will now appear inside the categories box on article pages for logged in users, which will directly launch the VisualEditor category dialog. [4]
• View all 34 community-submitted tasks that were resolved last week. For example, there was a problem downloading pdf files last week and that has been resolved. [5]

Updates for technical contributors

• The field rev_sha1 in the revision database table is being removed in favor of content_sha1 in the content database table. See the announcement for more information.
• The Reader Experience team will roll out Dark Mode user interface on all Wikimedia sites on October 29, 2025. All anonymous users of Wikimedia sites will have the option to activate a color scheme that features light-colored text on a dark background. This is designed to provide a more comfortable reading experience, especially in low-light situations. Template authors and technical contributors are encouraged to learn how to make pages ready for Dark mode and address any compatibility issues found in templates in their wiki before the enablement. Please contact the Web team for questions or any support on this talk page before the enablement. [6]
• Starting on Monday, October 6, API endpoints under the rest.php path will be rerouted through a new internal API Gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the Service Ops team board. [7]
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 17:19, 6 October 2025 (UTC)

One resolved issue not listed but may be of general interest is phab:T403900: "Watchlist expiry not set when saving page edit using HotCat". When adding or modifying a category within the HotCat interface (using its save instead of a regular edit save), our individual watchlist expiry preference setting was not being honored. Stefen 𝕋ower_{'s got the power!!1!} ^{Gab • Gruntwerk} 18:53, 6 October 2025 (UTC)

An edit link will now appear inside the categories box on article pages for logged in users, which will directly launch the VisualEditor category dialog. This feature quite annoyingly permanently sets your editor preference to VisualEditor, so the next time you go to edit a large page you're going to be stuck staring at the loading bar for a while waiting for VisualEditor to load so you can switch it back. --Ahecht (TALK
PAGE) 16:41, 8 October 2025 (UTC)

I just tried to see what happens with me. I did not attempt to change any categories. Exited the dialog which dropped me into VE. Couldn't exit VE because I hadn't made any changes but hit refresh on the edit button. Dropped straight into 2010 WTE. (Which I confirmed after to see if I was in 2010 WTE on a separate page.) What are your editor settings at Special:Preferences#mw-prefsection-editing in your ideal, what process do you precisely follow, and what are your editor settings after? My editor settings are:

• Enable the editing toolbar
• Enable the visual editor
• NOT Use the wikitext mode inside the visual editor, instead of a different wikitext editor
• Always give me the source editor.

Izno (talk) 16:53, 8 October 2025 (UTC)

I subsequently tried the above but edited the page this time. I am still dropped into 2010 WTE at the end of it all. Izno (talk) 16:55, 8 October 2025 (UTC)

They almost-certainly have "remember my last editor" as their editor preference, as that's the only way this feature would affect your next edit session. In fairness, this is the default, so we should be thinking about potential confusion it might cause. That said, they-specifically might be better served by switching to either always-source or show-tabs, given their dislike of winding up in VE accidentally.

Separately, it's interesting seeing the comments about it being difficult to exit VisualEditor. I may be too close to this topic, but I can think of a number of ways to do it: use the browser back button, click the "read" or "article" tabs, or press ESC. (Admittedly, I discovered a bug while testing making that happen during the loading animation, which is filed as phab:T406803.) The main reason that there's not an explicit "exit" button in the toolbar by publish is that we're a bit space-constrained and all those other methods exist... but I'm not averse to thinking about it more if it turns out to be more of a problem than I realized for people? DLynch (WMF) (talk) 03:13, 9 October 2025 (UTC)

I tried esc then and I just to verify I tried it now, outside of the loading animation. Neither worked. Firefox up to date on Windows 10. I was pretty sure it was supposed to work but it didn't. Izno (talk) 03:53, 9 October 2025 (UTC)

Oh, there's an annoying quirk to specifically using ESC to leave VE. If you're on an article where an edit notice is shown, it'll first close the edit notice... and then you need to get your keyboard focus back to the edit surface before pressing ESC again will leave VE.

(The toolbar swallows that use of ESC because there it means "close the current popup". Though it's probable that it should bubble up to the leave-the-editor behavior if there's no open popup, because that'd be consistent with how ESC behaves when there's a context popup open in the edit surface...)

So, another ticket has come from this to make that behavior around edit notices a bit more sensible: phab:T406807 DLynch (WMF) (talk) 04:44, 9 October 2025 (UTC)

Ah yup, that was an article (World of Warcraft) with an edit notice. Izno (talk) 04:51, 9 October 2025 (UTC)

But yes, I do think the interaction with this edit button -> launch tool -> get dropped into VE regardless of settings is a miss and should be fixed. If possible the specific system set up should be launched as separate from VE (similar to the TemplateData editing tool I suppose). Izno (talk) 03:57, 9 October 2025 (UTC)

The main difficulty with pulling it out as a separate system is that there's not a "change the article's categories" API available, so what it'd need to do is something like load VE hidden in the background so it can make the edit and save it. (HotCat does similar, though it's wikitext-based so it loads the full article wikitext and manipulates it to try to adjust the categories that way.) This is possible, but does rather take the feature out of the quick-improvement category. DLynch (WMF) (talk) 04:48, 9 October 2025 (UTC)

Yes, I thought that might be the case (it magically appearing was not on my radar). "If possible" and/or a task for general improvement there.

Loading VE hidden in the background wouldn't be totally unlike how VE does section editing for WTE 2017 I guess which IIRC is just like "let's load the whole article but only display the wikitext for the specific section". Izno (talk) 04:54, 9 October 2025 (UTC)

Fairly different, unfortunately -- 2017 section editing just loads the wikitext and displays it in a text editor with all the VE UI showing. It doesn't do all of the data-model stuff that VE does, and it's not trying to hide anything while the editing is happening. It also doesn't need to do anything to reconstruct the full wikitext itself, because there's APIs that it can offload that to. (Ultimately it's a skin over all the same behavior as the core source editor.)

Strictly, with the way it's designed, there's nothing stopping us from loading just VE's data-model and directly interacting with it or using its UI tools (like the categories dialog) then triggering a save. However, we've never actually done that, so it'd need a bunch of examination for places where we're making assumptions that of course there's a contenteditable surface involved. DLynch (WMF) (talk) 16:06, 9 October 2025 (UTC)

(It is nice this tool is being exposed, of course, though I suspect most power users are using HotCat to change categories if that's one of their missions in life, which I would guess is a lot slimmer solution in general than the categories tool in VE.) Izno (talk) 03:59, 9 October 2025 (UTC)

Yeah, HotCat is entrenched particularly on enwiki. However, it's not installed/default-enabled on most other wikis -- even the big ones. So adding something like this gets us to a place where a lot more people have quick access to category-editing than before, when it was fairly hidden away from them -- either because they used VE and didn't realize where that dialog was or that you could click to edit categories after you'd entered VE, or because they used source mode and didn't understand how to find categories in wikitext. DLynch (WMF) (talk) 04:26, 9 October 2025 (UTC)

Yes, the factors of "HotCat is ancient" and "HotCat is used only on a few wikis" and "HotCat is a gadget" were all quite obvious to me. :) Izno (talk) 04:38, 9 October 2025 (UTC)

Sorry, I've spent most of the day explaining technical things to people, and I might be falling back on that when it's unnecessary. 😅 DLynch (WMF) (talk) 04:49, 9 October 2025 (UTC)

There are audiences besides me, indeed. Izno (talk) 04:51, 9 October 2025 (UTC)

Hotcat may be "ancient", but that's not necessarily a bad point. As for it's not installed/default-enabled on most other wikis -- even the big ones, out of 84 wikis where I have made at least one edit, at least 48 of them have HotCat available in Gadgets (see e.g. fr:MediaWiki:Gadgets-definition, de:MediaWiki:Gadgets-definition). Of those where it is installed, you're right that those where it's enabled by default are in the minority. --Redrose64 🌹 (talk) 20:09, 9 October 2025 (UTC)

Update: I've carried out a thorough check of those 84 wikis. 75 have HotCat installed, of which six (ceb:MediaWiki:Gadgets-definition, c:MediaWiki:Gadgets-definition, kk:MediaWiki:Gadgets-definition, or:MediaWiki:Gadgets-definition, tl:MediaWiki:Gadgets-definition and tr:MediaWiki:Gadgets-definition) have it set as enabled by default (note that one of them is Commons, certainly a "big" wiki. Of the nine which do not have HotCat installed, six (an:, cy:, eml:, gd:, lij: and vo:) are not set up for gadgets at all. The three wikis with gadgets but not HotCat are: am:MediaWiki:Gadgets-definition, bar:MediaWiki:Gadgets-definition and voy:en:MediaWiki:Gadgets-definition. --Redrose64 🌹 (talk) 21:15, 9 October 2025 (UTC)

@DLynch (WMF) I did have that setting set to "remember my last editor", but as you said, I never explicitly chose that option as it was the default, and wouldn't have known to even look for that setting existing had it not been for this discussion. On your second point, it's not exiting per-se that's the problem, it's exiting in such as way that switches back to the text editor.--Ahecht (TALK
PAGE) 16:19, 9 October 2025 (UTC)

Help expanding help page: Help:Whitelist Wikipedia on your VPN

I started this help page because people often do not know that they even have a VPN enabled. Unfortunately there are only two prominent browser/device VPNs listed: iCloud Private Relay, and Microsoft Edge Secure Network. I only think we should have common browser VPNs listed like these two, as well as other VPNs that may ship with browsers in the future like Mozilla VPN or Opera VPN (as opposed to VPNs that might not ship with browsers like ProtonVPN or NordVPN or ExpressVPN).

If I recall, there are already discussions about how we can accommodate VPNs as they may not be easy to turn off (if at all) in the future. It would especially be helpful for {{webhostblock}} which already names iCloud Private Relay and Microsoft Edge Secure Network. Aasim (話す（はなす）) 01:13, 7 October 2025 (UTC)

Awesome Aasim, why not non-browser VPNs? — Qwerfjkltalk 08:58, 7 October 2025 (UTC)

I don't know if such advice would be quite helpful given these other VPNa are separate programs that one consciously has to download. But if you think it is a good idea, go ahead and add that information. Aasim (話す（はなす）) 11:08, 7 October 2025 (UTC)

Ah, skipped over the first sentence. Maybe still useful, but I'll leave it up to others. — Qwerfjkltalk 14:52, 8 October 2025 (UTC)

The desktop view on mobile (Chrome on Android) has gone zoomed out again

The problem

• 
  A screenshot of vector 22 desktop not working on Mobile
• 
  A screenshot of vector 22 desktop not working on Mobile

Not sure if it's just something on my setup, but from today the site is coming in zoomed out when I load pages in desktop view on mobile. And when zooming in, it doesn't adjust the text to match, it just extends beyond the screen edges. This makes it much more difficult to read and edit pages.

This has happened a few times in the past when some sort of viewport or other change is made to the skins. Has there been any such change today or on the recent past? Cheers  — Amakuru (talk) 14:45, 7 October 2025 (UTC)

Yeah, this is what was happening in #Old mobile skin changed? and I just couldn't think of a non-technical way to describe it to the user there. I can't say why it's happening either. And right now, we're still approaching the end of the mobile domain which may (already) be affecting what's going on here.

That said, I would generally expect the desktop view to act like this, even on mobile, as it does on most other websites, new viewport or not. Or at least, the desktop view accessed by the "use desktop view" in the browser options rather than the link at the bottom of pages. Izno (talk) 16:46, 7 October 2025 (UTC)

thanks for the response. My experience currently is largely the same whether the "desktop view" flag in the browser is checked or not... In vector 2022 incidentally, not 2010. Something very similar happened a few years ago after a patch of some sort and there was a lot of complaint, because it makes it very difficult for us to do our day to day editing (and yes, I know desktop view on a mobile isn't a mode WMF encourages, but for serious editing I find mobile view pretty limited. Historically it's always worked very nicely but it's broken currently). Is there a workaround? I couldn't quite figure it out from the thread you mention. Thanks  — Amakuru (talk) 17:21, 7 October 2025 (UTC)

I don't know. I also don't know if it's worth reporting upstream or not. I am myself kind of in the mode of "wait for the sunsetting of the mobile domain that will be here some time before the end of this month" to see if this issue now-reported resolves itself. Izno (talk) 17:50, 7 October 2025 (UTC)

This is a mess. I always use the desktop view on my phone. The new layout is almost impossible to read with very long lines that don't fold properly. I came here to ask about this and found several ongoing threads, so it must not just be me. RoySmith-Mobile (talk) 17:50, 8 October 2025 (UTC)

Could you share some screenshots? Nothing has changed here that I am aware of so I am curious about what you are experiencing. 🐸 Jdlrobson (talk) 00:05, 9 October 2025 (UTC)

@Jdlrobson there are some in the linked #Old mobile skin changed?, which is usually a symptom of a viewport issue. Izno (talk) 00:41, 9 October 2025 (UTC)

And I missed you had asked about things there. Anyway, I assume it's the same symptom, but I guess we can wait for Roy and Amakuru to comment. Izno (talk) 00:42, 9 October 2025 (UTC)

Those screenshots are Minerva. This is claiming issues with Vector 2022. 🐸 Jdlrobson (talk) 01:37, 9 October 2025 (UTC)

There are like 12 different rendering modes that can happen these days, it is REALLY important that people post screenshots, detail which browser on which platform they are using and if they are using/have used the “request desktop/mobile website” option of the mobile browser, if we want to figure this out. A couple of days ago an issue that was specific to SamsungBrowser was fixed, it just takes gathering information to figure things like this out. —TheDJ (talk • contribs) 08:30, 9 October 2025 (UTC)

Replying as the OP of the aforementioned post, switching to "mobile view" and logging out returned the viewport back to zoomed in again. As for editing in Vector 2022, I couldn't tell you. (What worked for me in Vector 2010, was that I switched to "mobile view" and appended ?useskin=minerva to the URL, which now displays every page zoomed in when switching from desktop to mobile, i.e. is responsive.) 8rz (talk) 10:22, 9 October 2025 (UTC)

Same problem here. Chrome on Android, screenshots attached, desktop mode selected, user script to force loading desktop, still happens incognito, also happens on commons. ScottishFinnishRadish (talk) 23:17, 9 October 2025 (UTC)

@TheDJ and Jdlrobson: here are a couple of screenshots of reading and editing this very page. The text is generally tiny, and when you zoom in it goes off the screen to the left and right. [8][9]  — Amakuru (talk) 23:22, 9 October 2025 (UTC)

The best part is that if you use the browser zoom enough to read the text it hides the watchlist button (???) but leaves the appearance button. ScottishFinnishRadish (talk) 23:27, 9 October 2025 (UTC)

What fun 😁🤔  — Amakuru (talk) 00:07, 10 October 2025 (UTC)

So I think I can replicate what you are seeing in the latest Chrome which shipped over the last week. The issue is not in the previous versions of Chrome which is why this has been confusing to debug.

Could you take a look at https://fbf5118949.catalyst.wmcloud.org/wiki/Paris on your mobile phone (imagining it is Wikipedia) and tell me if this wiki has the same issues as the ones you are experiencing on English Wikipedia.

If so I can link to the task we have in Phabricator. If not, I'll be back with more questions ː-) 🐸 Jdlrobson (talk) 01:25, 10 October 2025 (UTC)

Hi, yes that one had the same issue.  — Amakuru (talk) 07:46, 10 October 2025 (UTC)

Same issue there. ScottishFinnishRadish (talk) 09:17, 10 October 2025 (UTC)

thanks.

1) could you share what device you are using Chrome on? The make and model?

2) can you go back to https://fbf5118949.catalyst.wmcloud.org/wiki/Paris and use the browser zoom function. Do any of those options look more like you expect.

3) by any chance is responsive Vector what you are actually requesting? https://fbf5118949.catalyst.wmcloud.org/wiki/Paris?useskin=vector-2022 🐸 Jdlrobson (talk) 17:27, 10 October 2025 (UTC)

1. TCL 60 XE NXTPAPER
2. No
3. No

ScottishFinnishRadish (talk) 18:09, 10 October 2025 (UTC)

@ScottishFinnishRadish could you clarify what is broken in your screenshot? It's not obvious to me what your exact complaint is given your answers to the above so I think your concerns might be different to other posters here. 🐸 Jdlrobson (talk) 18:19, 10 October 2025 (UTC)

Jdlrobson

It's broken.

Before it became broken, actually readable.

Now it's broken and unreadable. Zooming in requires panning the screen to read.

@Amakuru, RoySmith, and RoySmith-Mobile:, does this match your experience? ScottishFinnishRadish (talk) 18:43, 10 October 2025 (UTC)

The latest version of Chrome has different font size compared to older versions in my testing, so this is likely what you are seeing. Do you have similar problems when you view the site in another browser (e.g. Firefox) and switch to desktop mode using the link in the footer? 🐸 Jdlrobson (talk) 21:06, 10 October 2025 (UTC)

Just installed Firefox and it's looking correct there. In Chrome no matter what method I used to get to the desktop site I got the zoomed out display. ScottishFinnishRadish (talk) 21:46, 10 October 2025 (UTC)

Man Writing a Letter

The first reference on Man Writing a Letter doesn't work.

I don't know what template to use for that. Io Herodotus (talk) 13:39, 8 October 2025 (UTC)

The template I think you are looking for is {{dead link}}. I corrected the problem by using the archive.org page for this book rather than Google Books as it allows you to actually read the text. -- Reconrabbit 14:02, 8 October 2025 (UTC)

Thank you. There is no painting called Man Writing a Letter by Gerard ter Borch.--Io Herodotus (talk) 14:14, 8 October 2025 (UTC)

Sutton writes on pages 58 and 96 about Gerard ter Borch's An Officer Writing a Letter, which is the presumed correct title. Anyway, this conversation is better had on the Man Writing a Letter talk page. -- Reconrabbit 15:47, 8 October 2025 (UTC)

OK, I made the transfer Io Herodotus (talk) 17:48, 8 October 2025 (UTC)

Collapsing part of a Wikitable

Request for additional functionality. The snooker maximum breaks table is getting very large, and so I would like to make the table smaller and more user-friendly by putting in an extra row above each season, with a "hide/show" button in it so that the user can selectively collapse/expand each season. Using nested tables seems to be the only way to do this currently, but that would compromise the table sorting, which is essential. See this discussion, which also has a sample of how the first 15 entries of the table might look. I posted this question in ⚓ T406703 Collapsing part of a Wikitable and they suggested posting here. Any help would be appreciated.  Alan  (talk) 17:53, 8 October 2025 (UTC)

What you want to do is not possible without the issue you already identified. That the table is tall is not of particular concern. In the two main skins, users have ways to get around (Vector 2022 has an ever-present table of contents and Minerva collapses whole sections). Izno (talk) 19:10, 8 October 2025 (UTC)

I have added an index to the table to help find years of interest.[10] PrimeHunter (talk) 20:33, 8 October 2025 (UTC)

Thank you, that is very useful. Although it behaves unexpectedly if the table is sorted by anything other than the default. I might change it at some stage from calendar years to snooker seasons. The original question remains though, and it seems as if I am asking the impossible, so I'll give up, but thank you again.  Alan  (talk) 07:35, 9 October 2025 (UTC)

See also Help talk:Collapsing tables and more#Collapsing part of a Wikitable. Is there anywhere else that this matter was raised? --Redrose64 🌹 (talk) 15:59, 9 October 2025 (UTC)

Yes - I also raised it in Template talk:Collapse#Collapsing part of a Wikitable. There were no responses. Feel free to delete those two if you like.  Alan  (talk) 16:09, 9 October 2025 (UTC)

@PrimeHunter: The ability to sort this table is very important, especially sorting by players' names. If the table is sorted by anything other than the default, then using the "Table TOC" produces unpredictable results. I have played around with it in a sandbox, but could not get it to work properly. Although your edit obviously took a lot of work, and was made with the best of intentions, I am am tempted to revert it since it could cause confusion. Would you object to having it reverted?  Alan  (talk) 19:06, 9 October 2025 (UTC)

@AlH42: We don't have a feature to hide or change content if a table is sorted. The year links work from the beginning and if the table is sorted by any of the first three columns. I don't know how many readers use sorting but if they sort by something nonchronological then I guess most of them don't expect a year link to give a sensible result. Worst case, they click a year link after sorting by something unrelated, see that it doesn't go back to sorting by year or whatever they expected, and then they can just sort by the no., date or season column if they want that. I don't think avoiding this is worth removing a useful feature. PrimeHunter (talk) 19:45, 9 October 2025 (UTC)

@PrimeHunter: Point taken. I was going to change it from calendar years to snooker seasons, but I now think it's probably best left the way you had it. It might be an idea to add a note underneath the TOC informing users that the TOC is only valid for the default sort.Thank you again.  Alan  (talk) 20:18, 9 October 2025 (UTC)

Inherit header color

Alan Dillon
Personal details
Born	(1982-09-28) 28 September 1982 Castlebar, County Mayo, Ireland
Personal information Sport Gaelic football Height 1.81 m (5 ft 11 in)

In the sample at right, I've got {{Infobox Gaelic games biography}} embeded in {{Infobox officeholder}}. Is there some bit of code I can use to get the embeded infobox to inherit the header color from the parent? I.E. make it so these two have the same colors when they are embeded or is this a limitation of Module:Infobox? --Zackmann (^{Talk to me}/_{What I been doing}) 18:06, 8 October 2025 (UTC)

Through no intention on my part, this should be possible by moving the module you're embedding, and the template containing the embedded template, to TemplateStyles. Izno (talk) 19:08, 8 October 2025 (UTC)

@Izno: can you give me a little more or link me to an example/documentation? When you say move it to TemplateStyles, what does that mean/look like? Zackmann (^{Talk to me}/_{What I been doing}) 19:13, 8 October 2025 (UTC)

It's currently not documented for infoboxes, but I did some job of documentation in the context of Template:Sidebar. Basically, infoboxes and sidebars (navboxes too, and more amboxes for certain reasons but these should least be used to attempt to maintain a standard appearance) take a |templatestyles= parameter that you can use (in the same way you would use a templatestyles tag's src attribute). There are some pre-established general classes corresponding to parameter names e.g. infobox-header, and for any others you add some classes in the infobox definition template page. Then you put the styles associated to relevant classes on the TemplateStyles page, prefixed with the class you assign to the infobox in whole in its |bodyclass= or equivalent.

In this case, the parent I would give the class ib-officeholder, the module ib-gaelic-games-bio, then I would add colors in their respective TemplateStyles sheets with .ib-officeholder .infobox-header { background-color: foo; } and .ib-gaelic-games-bio .infobox-header { background-color: bar; }. And that should be it, per the below first paragraph. Izno (talk) 19:20, 8 October 2025 (UTC)

And I say through no intention on my part, because what Module:Infobox seems to do today is absorb modules directly into the table presented (rather than create subboxes). Or at least, it does so for other Module:Infobox infoboxes. This causes some information from the embedded module to be lost somehow, among other items its TemplateStyles output.

IDK if this behavior will survive. If it is desirable generally (this is not the first time I've heard this request), and I think it probably is, it's something that embedded modules can be adjusted into the arbitrary future to do. Izno (talk) 19:14, 8 October 2025 (UTC)

The issue with just always doing it is that TemplateStyles will have both the overrides for the generic parameters as well as template-specific styles necessary, so that issue is something to think about. Izno (talk) 19:26, 8 October 2025 (UTC)

Discussion at Wikipedia:Village pump (proposals) § Modify template:red and template:gray to be WP:COLOR-compliant

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § Modify template:red and template:gray to be WP:COLOR-compliant. Sapphaline (talk) 20:01, 8 October 2025 (UTC)

Element ID of cancel button

Writing a user script and I'm stuck editing on an iPad at the moment and can't inspect my source code. Can someone help me out with what the elementid of the cancel button is when editing source code on wikipedia? Can't find this documented anywhere... I know I can do document.getElementById('wpSave').click(); to click the save button. What is the equivalent for the cancel button? Zackmann (^{Talk to me}/_{What I been doing}) 23:18, 8 October 2025 (UTC)

mw-editform-cancel is the span around the a. It is not actually a button, though the a claims the button role in what is a sadness for the accessible web. Izno (talk) 23:30, 8 October 2025 (UTC)

Thank you!!!!! - Zackmann (^{Talk to me}/_{What I been doing}) 23:43, 8 October 2025 (UTC)

@Zackmann08 document.querySelector("#mw-editform-cancel a").click(); works, or you can use $("#mw-editform-cancel a span").click(); if you want to bypass the confirmation dialogue. --Ahecht (TALK
PAGE) 16:03, 9 October 2025 (UTC)

Image rotation

I asked at Wikipedia:Help desk#Image rotation for help with a rotated image problem. It was fixed at c:File:Sankhadhar statue.jpg but it's still wrong at File:Sankhadhar statue.jpg and in articles Sankhadhar Sakhwa and Nepal Sambat#Reinstated as national calendar. What else is needed to have the image upright? Johnuniq (talk) 23:25, 9 October 2025 (UTC)

It looks fine to me now, after purging it on commons and refreshing my browser. - Erik Baas (talk) 00:35, 10 October 2025 (UTC)

OMG, thanks. I tried purging everything but not my browser. Johnuniq (talk) 03:46, 10 October 2025 (UTC)

Yes, this sort of thing can usually be traced to client-side caching. --Redrose64 🌹 (talk) 19:55, 10 October 2025 (UTC)

Stray closing strong tag in MediaWiki:Protect-text/de

An unmatched closing </strong> tag has shown up in MediaWiki:Protect-text/de. It is also present in that same file on other MediaWiki sites (e.g. the version on Wikidata). Does anyone know where it came from and how to get rid of it? – Jonesey95 (talk) 02:38, 10 October 2025 (UTC)

@Jonesey95: Interface message translations are from translatewiki. Removed; the content should be synchronized in a few days. NguoiDungKhongDinhDanh 02:42, 10 October 2025 (UTC)

Thanks. I found that translatewiki site but was unable to figure out where to go to fix the message. – Jonesey95 (talk) 12:07, 10 October 2025 (UTC)

The original message in English has a strong in it, so I would think the opening tag should be added rather than the closing tag removed. Izno (talk) 17:01, 10 October 2025 (UTC)

Querying APIs from templates

Is it possible to query the Search/Wikidata APIs from a template? I'm interested in potentially using this API within a talk page template to fetch high-quality exemplar articles that could be used as models to improve a given article. Sdkb ^talk 03:26, 10 October 2025 (UTC)

You can link to it, but otherwise no. Neither Lua nor templates can make lists in general. Izno (talk) 17:01, 10 October 2025 (UTC)

Thanks for answering, @Izno. I'm looking mainly to fetch the top result, not to make an entire list. What technical work would need to be done to make querying possible? i.e. is there a different platform that it'd need to be hosted on? Sdkb ^talk 19:50, 10 October 2025 (UTC)

I'm not making it but a gadget or sitewide JavaScript could do it. However, we want to limit those things, and it would also use server resources on every page view. A compromise could be a button to generate the data on command by reloading the page with a withJS parameter to run a script in the MediaWiki namespace. We implement withJS in MediaWiki:Common.js but don't use it much. Here are some examples. PrimeHunter (talk) 09:23, 11 October 2025 (UTC)

Yes, but to fetch the top result, you still need to make a list to compare the top to everything else.

Is there a different platform that it'd need to be hosted on? This would have the same requirements as PH's commentary. (You will never be able to access non-production systems via templates/Lua, so that includes your preferred API.)

What technical work would need to be done to make querying possible? Well, building and adding some extension that does what you want it to. Izno (talk) 22:21, 12 October 2025 (UTC)

Did something about login change, again?

My bot stopped being able to log in, as has happened several times before.

My bot uses more or less the login scheme described at https://en.wikipedia.org/w/api.php?action=help&modules=clientlogin .

But it's getting "Invalid CSRF token" when performing the action=clientlogin step.

Previously, the bot wasn't using a CSRF token at that step — it was fetching the CSRF token later.

I tried fetching the CSRF token earlier, and including it in the action=clientlogin step, but it didn't help.

Although, the CSRF tokens I'm getting look bogus, so perhaps the process of correctly fetching those has changed.

I dunno. Does anyone know? —scs (talk) 04:35, 10 October 2025 (UTC)

The api help says you need a login token instead of a csrf token. hgzh 05:40, 10 October 2025 (UTC)

@Hgzh: Yup. Nevertheless, "Invalid CSRF token" is what it was complaining about. —scs (talk) 11:58, 10 October 2025 (UTC)

A login token is a specific type of CSRF token that's used for logins. I suppose it's a little confusing that "csrf" is one of the other types of CSRF token, used for general actions that don't use a more unique token. Anomie⚔ 14:16, 10 October 2025 (UTC)

@Anomie: Yikes. I had no idea. Yes, that is a little confusing!

For a while now, because I thought it had to, my bot has been fetching a "csrf" token and saving it (in the manner of a cookie) to be resubmitted with all requests. Today, I notice that the "csrf" token it's getting is just the two characters "+\", which doesn't seem like much entropy. I'm wondering if this might be another clue into the source of my problems. —scs (talk) 14:46, 10 October 2025 (UTC)

A CSRF token (of whichever type) is needed for any Action API endpoint that has a token parameter. The docs for the parameter will tell you which type. If the Action API endpoint doesn't have a token parameter and you submit one anyway, generally it'll just give a warning and ignore it.

The "+\" token is the "csrf"-type token given to logged-out users, to avoid having to do all the server-side token and session storage stuff when there's not much that a cross-site forged request might actually do. As you note, it doesn't really serve to actually prevent CSRF. Some of the factors that went into that tradeoff 20-some years ago may have changed since, but T40417 doesn't seem to have gone anywhere yet. Anomie⚔ 14:56, 10 October 2025 (UTC)

My goodness. "Doesn't seem to have gone anywhere yet." ISWYM. —scs (talk) 19:43, 10 October 2025 (UTC)

Just an FYI, clientlogin is for interactive applications, not for bots, which should use the action=login with a bot password, or OAuth. When you use clientlogin, you could be presented with things like captcha challenges, emailauth, 2fa etc, which might require an HTML form. —TheDJ (talk • contribs) 07:39, 10 October 2025 (UTC)

@TheDJ: Ah, yes. Right. I don't know why I had never gone down the bot password route. Good suggestion; thanks. (But see below.) —scs (talk) 11:58, 10 October 2025 (UTC)

trouble with bot password

I'm quite belatedly trying to set up a bot password for my bot, but so far it's not working.

I went to Special:BotPasswords, and I seem to have generated a bot password for "Scsbot@RD_archiver".

But when the bot tries to log in, with lgname=Scsbot@RD_archiver, and lgpassword =the newly-generated bot password, and action=login (not action=clientlogin as before), it's failing with the reason "Unable to continue login. Your session most likely timed out."

I suspect there's something wrong with the bot infrastructure's cookie handling, which I'm reviewing. But I'd welcome any other suggestions. —scs (talk) 12:33, 10 October 2025 (UTC)

The error means that the login token changed between when you fetched it and and when you sent it back to action=login. This is typically because your bot isn't holding on to cookies.

If you have trouble with BotPasswords, note that OAuth is a much smoother way for bots to authenticate. See mw:OAuth/Owner-only consumers#OAuth 2. It doesn't require any logins or cookies – you just have to send an Authorization header in requests. – SD0001 (talk) 13:52, 10 October 2025 (UTC)

@SD0001: I'm puzzled when you say "typically because your bot isn't holding on to cookies", because aiui, the login token is explicitly passed in the API request URL; it is not a cookie. Are you referring to other cookies that are processed in conjunction with the login token? (But, yes, in general, while this bot does handle cookies, I suspect its handling is imperfect in some way that didn't matter until this week.) —scs (talk) 14:34, 10 October 2025 (UTC)

On the server side your token is stored in the session. If you're not properly handling the session cookie, it will keep trying to generate a new session and a new token. Anomie⚔ 14:41, 10 October 2025 (UTC)

And, indeed, there were problems with the way my HTTP processor was handling cookies. (There were some fixed-size buffers, and the session cookie sessionJwt seems to have recently grown to almost 900 characters.) So after fixing those issues, and then a few more that cropped up, the bot seems to be working again. Thanks for everyone's help. —scs (talk) 04:22, 11 October 2025 (UTC)

Painting the bike shed

Hey, all: Wikipedia:Village pump (proposals)#Change the Village Pump's colour. is trending towards consensus to change the color of Template:Village pump page header from brown to a light purple. I'm posting this because, as our highest-traffic Village pump page, I don't want you to be surprised when it changes. As with all changes to appearances, y'all know that it may take a few days to get used to the new color, and someone usually complains, so if someone complains here, please send them our way. WhatamIdoing (talk) 16:09, 10 October 2025 (UTC)

+1 wikipoints for your heading 🤣 Sdkb ^talk 19:57, 10 October 2025 (UTC)

I was so disappointed when I learned that the iconic story behind the Law of triviality was a fictional example. WhatamIdoing (talk) 20:27, 10 October 2025 (UTC)

Ah, another FaviFake thing. --Redrose64 🌹 (talk) 19:57, 10 October 2025 (UTC)

Hardly the only supporter. FaviFake dangled a worm and quite a few editors took the hook, including yours truly. There is nothing wrong with dangling a worm. ―Mandruss ☎ IMO. 10:11, 12 October 2025 (UTC)

WaId, you have more patience with ridiculosity than I. My position is "Get over it." Last time I checked, we are the most adaptable species currently on the planet. The rest of the internet changes for most of us on a near-daily basis, and most of us absorb the change without missing a beat. Coddle people and they become weaker, but only in the environment where they are coddled. I oppose coddling. ―Mandruss ☎ IMO. 10:14, 12 October 2025 (UTC)

I demand an option in Special:Preferences to see the old colour! /jk the wub "?!" 10:57, 12 October 2025 (UTC)

I know you're joking, but the ability to adjust this with a user script was seriously proposed. IMO the color of the box is so trivial that it's not worth fighting over. If folks want it to be purple, then let it be purple! Let them pick a new color each year, if they want. And if "I" want it to be brown, or green, or a more mauvy shade of pinky russet, then there's nothing wrong with me creating my own CSS code to do that (or, you know, asking one of y'all if you'd be willing to do that for me, because I don't know how). WhatamIdoing (talk) 18:41, 12 October 2025 (UTC)

Another discussion on this page is proposing that every message box be designed to support being skinned. While it's technically possible for every design element to be written in a way that various visual features can be overridden in a skin or a personal style file, I don't think the benefit/cost ratio is sufficiently high that it should be mandated and backported for everything. If someone wants to voluntarily support skinability in a specific widget, sure, as long as it doesn't make it too difficult to find someone to maintain it in future. (It's not that hard for people who understand CSS, but there are plenty of editors who react with a "I can't do it!" when hearing the word "template", much less "CSS".) isaacl (talk) 22:51, 12 October 2025 (UTC)

I would have argued this before LLM and autonomous agent coding tools became somewhat workable (with many caveats). Making a widget skinnable is one of the class of problems that automated coding agents can do competently and cheaply. I can flop a dark mode onto any existing thing with a single prompt using GPT-5. Yes, check it and make sure the LLM hasn't barfed up a hallucination, but while I would have argued themable UI was a nice-to-have prior to this generation of automation, at this point it is easy enough to do and low enough risk. Andre🚐 23:12, 12 October 2025 (UTC)

As Izno says, it's pretty easy to do; no LLM necessary. The layout just needs to follow some basic CSS principles. Like I said, my concern is about mandating this for all new widgets and requiring all existing widgets to be retrofitted, for the benefit of what I think will be a small number of editors, and complicating support costs for them since their UI will differ from everyone else's. isaacl (talk) 01:00, 13 October 2025 (UTC)

I add TemplateStyles on occasion solely because I want to make it easier to skin things. In some other cases it's enough just to add a class to a template or other transcluded item. Izno (talk) 00:04, 13 October 2025 (UTC)

I suggest using https://bikeshed.toolforge.org/ to pick a new color. AntiCompositeNumber (they/them) (talk) 01:20, 13 October 2025 (UTC)

Can't change skin.

While I was viewing a talk page, I had accidently clicked a button on my mouse that changed the skin to the mobile skin. And I tried to change the skin, but it did not work and it is stuck on the same skin. NicePrettyFlower (talk) 23:49, 10 October 2025 (UTC)

At the very bottom right of a desktop page, there is a "mobile view" link which switches you to the mobile view. Once there, the same location has a "desktop" link which switches back. Johnuniq (talk) 00:23, 11 October 2025 (UTC)

I did it and it worked. Thank you. NicePrettyFlower (talk) 00:27, 11 October 2025 (UTC)

I think I figured out what we needed to satisfy everyone with regards to icon style and design... (icon packs)

A month or two ago there was an RfC to change the icons to use Codex styling. That mostly failed unfortunately, but I realize to satisfy the users instead of transcluding images in the mbox and user warning/block templates we use HTML/CSS classes, alongside the "background-image" attribute or something like that, I am forgetting.

We can and should still be able to define custom images, but this way it will be possible for users to have more customization options. Users can then create their own icon packs to set in Preferences, from Nuvola to MDN to OOUI to Codex, etc. This might be the best option to respect the consensus for "no change" while giving users some freedom into the different icon themes.

This would also have the added advantage of allowing us to (for substituted templates) go back and replace each of the file links with appropriate CSS instead (somewhat reducing server load, and also if consensus emerges to change the default it can be done retroactively as well). Just as we allow users to customize the skin, users should be able to customize the icons they see. CSS also has the added advantage of changing things retroactively. Aasim (話す（はなす）) 19:20, 11 October 2025 (UTC)

I see two problems with this idea:

1. CSS can't add a file link or change the target of the file link to point to the correct page, for any images where we can't suppress the file link entirely. So this would only be useful if all images involved are public domain, CC0, or the like. CC BY-SA, MIT, or most other licenses couldn't be used.
2. People will still argue over what the default "pack" should be.

Anomie⚔ 19:47, 11 October 2025 (UTC)

CSS can't add a file link or change the target of the file link to point to the correct page, for any images where we can't suppress the file link entirely. So this would only be useful if all images involved are public domain, CC0, or the like. CC BY-SA, MIT, or most other licenses couldn't be used. The majority of icons proposed (the image output) fall below the threshold of originality anyway (even though the SVG code may be protected as a computer program under MIT).

People will still argue over what the default "pack" should be. Maybe it should be that way to unify Wikipedia under one style. Aasim (話す（はなす）) 17:54, 12 October 2025 (UTC)

Currently the Codex icons, which are the exemplar of the flat style people have been pushing, are all under the MIT license. Until someone convinces Commons to change that to "doesn't meet the TOO", we need to honor it and have the link to the file description page to satisfy the license's requirement for including the copyright and permissions notice. Icons from the Noun Project, which I've also seen some flat-icon enthusiasts using, are CC BY, which again requires the link for attribution. And on the other side, while some of the non-flat icons we use, such as those from the Tango Desktop Project, are PD, many others such as the Crystal Project and various non-set icons, are not and almost certainly don't fall under the TOO. Anomie⚔ 18:11, 12 October 2025 (UTC)

Let's take an example icon: . I don't think this icon is above the threshold of originality.

Also OOUI and Codex icons ship with MediaWiki and their licenses are already listed on Special:Version. The other icons I do agree we will likely need some way to specify a license for the entire icon pack. Aasim (話す（はなす）) 18:44, 12 October 2025 (UTC)

Ignoring Anomie's concerns (at least one of which I don't agree with, but whatever), "defining custom images in CSS" is non-trivial compared to today. Izno (talk) 22:16, 12 October 2025 (UTC)

I am talking about using CSS classes and the background-image property to put in icons. This is already done for OOUI and Codex icons in the UI. We can do the same for our icons as well. Or we can define custom fonts with these icons maybe. Aasim (話す（はなす）) 00:35, 13 October 2025 (UTC)

Yes... you're missing the point. Today, all someone needs to do is |image=[[File:Example.svg|25px]]. That level of simplicity simply cannot be achieved in CSS. Izno (talk) 02:58, 13 October 2025 (UTC)

That aside, if someone wants to override arbitrary images, they already can: .mbox-image img { }. Izno (talk) 03:00, 13 October 2025 (UTC)

I have no idea what the error messages mean

Resolved

 – ―Mandruss ☎ IMO. 10:06, 12 October 2025 (UTC)

I returned to my common.js page to attempt to install the Evad37/rater tool after having it suggested recently, only to find that I had already installed it in 2020. I had obviously forgotten about it because it has not been operational, to my knowledge anyway. I don't recall seeing error messages before (and I have successfully installed and use Twinkle and an archiving tool), but I now see "Code that you insert on this page could contain malicious content capable of compromising your account. If you import a script from another page with "importScript", "mw.loader.load", "iusc", or "lusc", take note that this causes you to dynamically load a remote script, which could be changed by others...." etc. I tried re-copying the value as suggested on User:Evad37/rater, but that still returns the error. I am clueless about javascript so if anyone can offer advice in a very simplified way, I would be grateful. Can anyone here edit my page, by the way? Laterthanyouthink (talk) 02:59, 12 October 2025 (UTC)

The "Code that you insert on this page" notice is not an error message, but just a reminder; it is displayed whenever anyone visits their common.js page. jlwoodwa (talk) 03:04, 12 October 2025 (UTC)

Ah, thank you jlwoodwa. Now I just have to work out how to find and use that rater tool... Laterthanyouthink (talk) 04:23, 12 October 2025 (UTC)

On Vector (2022) desktop it is at the top of the drop-down list under "Tools". I haven't looked at any of the other skins in years. Donald Albury 17:51, 12 October 2025 (UTC)

Toolforge down?

Not getting to any of the tools I usually use, just error messages. Abductive (reasoning) 08:39, 13 October 2025 (UTC)

seems so.. —TheDJ (talk • contribs) 09:02, 13 October 2025 (UTC)

This is a result of ongoing scheduled maintenance, details of which are on the cloud-announce mailing list (that I apparently can't link to from this account due to an edit filter). Taavi-WMF (talk) 09:02, 13 October 2025 (UTC)

Back up, but unsure if permanently. Abductive (reasoning) 09:42, 13 October 2025 (UTC)

Maps backend upgraded to a new stack

Hi folks!

The SRE and Content Transform teams have been working for the past months to upgrade the Maps stack to a more up-to-date status (all the info in [11]). The Maps backends are two, one in the eqiad datacenter (Virginia) and the other one in the codfw datacenter (Texas), and users are transparently proxied to one of the other based on their location.

We have just upgraded/repooled the codfw datacenter, so the majority of the traffic is still not handled by the new stack. We are going to do more tests later on during the week, and I'll post a note in here every time.

One of the issues that may arise is tiles/maps being rendered differently: in some cases it is expected (for example, overlay text taking a slightly different position etc..), some other cases may be not (big difference in shapes, blank tiles/maps, etc..) so feel free to report anything suspicious in the aforementioned Phabricator task.

The previous attempt of this upgrade didn't go as planned (see Wikipedia:Village pump (technical)/Archive 224#h-Maplink wikidata broken?-20250827180200), tagging some people from it to loop them in. @AFC Vixen @Qwerfjkl @Gunnar Larsson @PrimeHunter @Home Lander @TheDJ (thanks in advance!). LToscano (WMF) (talk) 09:30, 13 October 2025 (UTC)

@LToscano (WMF) thanks for the update! One somewhat strange thing I have noted is the behavior on Danish Wikipedia. For example da:Grenaaen shows no map where it is supposed to show an OpenStreetMap map (i.e. below "Fysiske kendetegn"). If you however click on the map (to get a full page view) it shows as expected. The same code is used on Swedish Wikipedia where it shows as expected (sv:Grenåen). Might this be a consequence of the upgrade/repooling? (I am not super-active on Danish Wikipedia, so not sure for how long it has been like this - though the behavior has existed since at least last Thusday. Gunnar Larsson (talk) 09:49, 13 October 2025 (UTC)

No, that's a Parsoid, vs Legacy Parser issue. There is a html link in this usage, which breaks the cached reference ID. This is a known issue that is being worked on separately. —TheDJ (talk • contribs) 12:05, 13 October 2025 (UTC)