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

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Weird issue where Vector 2022 is being forced on a single page.

Tracked in Phabricator
Task T358304
Duplicate

Tracked in Phabricator
Task T336504
Resolved

So I use desktop Vector 2010 on mobile, and have a global preference set to enforce it. But when I go to Wikipedia:Sockpuppet investigations/PaullyMatthews (I was checking back on a report I made) I get Vector 2022 forced.

I can't find any reason why this page is forcing Vector 2022 (it's archive is doing the same). No other pages are effected, not even other SPI pages. -- LCU ActivelyDisinterested «@» °∆t° 22:40, 22 February 2024 (UTC)

I also saw that, and also on some other SPI pages. I'll bet it was a WP:THURSDAY feature. I've refreshed and purged a few times and it seems to have now gone (for me anyway). -- zzuuzz ^(talk) 22:50, 22 February 2024 (UTC)

Probably not, this has been happening to pages translcuding special pages (PrefixIndex in this case). See /Archive 210#One page looks like Wikipedia does now. Nardog (talk) 22:54, 22 February 2024 (UTC)

Force-refreshing the SPI page has fixed it for me. This wasn't the first time; I recall some other time that an editor at VPT found Vector22 being forced and the link to it caused me to see it as well. SWinxy (talk) 04:53, 23 February 2024 (UTC)

Happening on Module:RoundN too. SWinxy (talk) 02:50, 25 February 2024 (UTC)

I get Vector 2022 instead of my preferred Monobook on Wikipedia:Featured article candidates/Dorothy Olsen/archive1, three times out of four reloads. —Kusma (talk) 23:00, 22 February 2024 (UTC)

If I purge the archives and refresh I get the proper skin, but if I refresh again it's back to 2022. -- LCU ActivelyDisinterested «@» °∆t° 23:10, 22 February 2024 (UTC)

I'll just add that I've seen the same thing RoySmith (talk) 23:44, 22 February 2024 (UTC)

@STei (WMF) I'm guessing this may be related to the Edit Recovery feature you rolled out earlier today. RoySmith (talk) 00:36, 23 February 2024 (UTC)

I also have it on Wikipedia:Sockpuppet investigations/PaullyMatthews (my default skin in Vector2010). But a hard refresh fixed it, and presumably hardest refresh would do the trick too. 🌺 Cremastra (talk) 00:57, 23 February 2024 (UTC)

I've purged and refreshed the page, still the same problem. I'm using the desktop site on mobile, so the hardest refresh isn't an option (and why Vector 2022 is so very thoroughly broken for my purposes). -- LCU ActivelyDisinterested «@» °∆t° 02:25, 23 February 2024 (UTC)

Wow, this is bizarre. I'm now getting V22 on Wikipedia:Sockpuppet investigations/PaullyMatthews and Wikipedia:Featured article candidates/Dorothy Olsen/archive1! Looks like it's somehow sticky to those pages. RoySmith (talk) 02:34, 23 February 2024 (UTC)

I'm working my way through all the FAC pages listed at WP:FAC. So far, it's pretty repeatable that each /archive1 page I open up, it opens in V22. Doesn't seem to matter if it's a FAC I've ever looked at or not. Some unreproducible number of page reloads eventually gets me to the non-V22 version. RoySmith (talk) 02:57, 23 February 2024 (UTC)

I noticed this at Wikipedia:Articles for deletion/¡Tchkung! (2nd nomination). Extraordinary Writ (talk) 06:52, 23 February 2024 (UTC)

I likewise have the issue on this page: https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Log/2024_February_24 Cortador (talk) 19:08, 24 February 2024 (UTC)

Can confirm I'm having this problem on certain random pages, all under the Wikipedia namespace (mostly AFDs and SPIs), and it usually goes away when I refresh. I also have Vector 2010 as default. LilianaUwU ^{(talk / contributions)} 02:44, 25 February 2024 (UTC)

Late, but I have also been getting this once every few weeks for the last year or so -- one page (sometimes an article, sometimes a template, sometimes a userpage) will just randomly become obsessed with being in Vector 22 regardless of my own settings, CSS, et cetera. It is quite disruptive. jp×g🗯️ 09:36, 7 March 2024 (UTC)

Wrong skin on just one page

Tracked in Phabricator
Task T336504

I use the "Vector legacy (2010)" skin and all pages display as they should. Except one: Wikipedia:WikiProject Canoeing and Kayaking. This page displays using the new Vector skin. Why? — GhostInTheMachine ^{talk to me} 09:49, 23 February 2024 (UTC)

Yep, I see it — GhostInTheMachine ^{talk to me} 09:52, 23 February 2024 (UTC)

It's a bunch of pages, upstream regression. — xaosflux ^Talk 15:35, 23 February 2024 (UTC)

Yeah, but this one doesn't fit the pattern of transcluding Special:Prefixindex (which typically happens on sub-pages to create the back-link header). @GhostInTheMachine is this reproducible for you? RoySmith (talk) 15:50, 23 February 2024 (UTC)

@RoySmith that page does indeed transclude prefixindex, it is in the navbox. — xaosflux ^Talk 15:56, 23 February 2024 (UTC)

Ah, interesting. So now I'm wondering why I can't reproduce the problem on that page :-) RoySmith (talk) 16:11, 23 February 2024 (UTC)

Oh, now I just got it in V2022. Weird. RoySmith (talk) 16:16, 23 February 2024 (UTC)

The page is still being evil ... — Preceding unsigned comment added by GhostInTheMachine (talk • contribs) 17:00, 23 February 2024 (UTC)

I get the wrong skin on a number of module pages, but not all. Ones with the wrong skin include Module:Clade, Module:Biota infobox and Module:Goalscorers, but Module:Taxonbar and Module:Autotaxobox shows with the skin in my preferences (MonoBook). —  Jts1882 | talk  17:37, 23 February 2024 (UTC)

For me the first three also appear in the wrong skin, but the last two don't. It will be interesting to learn what's causing this. -- LCU ActivelyDisinterested «@» °∆t° 18:45, 23 February 2024 (UTC)

I've got the same issues as the people above but also with Wikipedia:Articles for deletion/Log/2024 February 23. It seems to resolve for a bit if I changed to the new skin and back in a different tab and refresh, but it reverts to the issue later. Shaws username . talk . 22:00, 23 February 2024 (UTC)

• I also stumbled across this - a random selection of AfD date pages appear in Vector 2022 for me. This RfA is in V2022, but this one appears in V2010. Bizarre! —Ganesha811 (talk) 15:48, 24 February 2024 (UTC)

Same, but some logs don't have the issue. Glad it's not my system. Star Mississippi 18:09, 24 February 2024 (UTC)

Shifting "skins"

Sorry if this has been brought up already but I do a lot of work on AFD daily log pages and they keep shifting skins. The layout can even change when I refresh the page. The view I don't want is a small middle column and two wide columns on either side. I'm used to the old view with a large middle column that has the majority of content and a top menu and only a right-hand side columns. There was a message at the top of a page that mentioned XFD discussion so I uninstalled that feature but it hasn't changed things for me. I have a week of AFD daily logs open in tabs and about 5 pages have the old view and 3 pages have the alternate view. Refreshing the page helped this morning (the view would switch back) but that doesn't work any longer. I've looked at my Preferences but nothing has changed there, still Vector Legacy.

It's strange how the layout of content really affects how I work and I find this new view, with tons of white space, off-putting. Any ideas how I can return things to normal for all AFD daily log pages? Thanks for any suggestions. Liz ^{Read! Talk!} 05:19, 24 February 2024 (UTC)

@Liz: Sounds like the same problem as Wikipedia:Village_pump_(technical)#Weird_issue_where_Vector_2022_is_being_forced_on_a_single_page. Where there are some cases where a page will use the new skin instead of the user's preferred skin. Or is this a different problem you are seeing? RudolfRed (talk) 06:02, 24 February 2024 (UTC)

Well, Wikipedia:Articles for deletion/Log/2024 February 17 was one particular page that just kept showing the alternate, white space skin (I should really learn their names). I did find I could hide the right-hand side menu which helped. But I just refreshed this page and got the old style came back so who knows? But this time, I was running into this phenomena on AFD daily log pages (as mentioned in the message below this one). I should have known it was a system bug, not just me, so thanks for moving my message to join others that mention similar problems. Liz ^{Read! Talk!} 20:07, 24 February 2024 (UTC)

Technical summary

Where Special:PrefixIndex is typically used

To summarize what's going on in a non-technical way, this appears to be a bug related to Special:PrefixIndex, which is used to generate the back-link header that's seen on subpages. A subpage is basically any page that has a slash in its title in certain namespaces (possibly all spaces except mainspace?). And what I'm calling the "back-link header" is the collection of links that take you back to the parent page. This is commonly seen in process pages such as WP:AfD, WP:SPI and WP:FAC. If you're seeing this on one of those kinds of pages, that explains it. If you're seeing this on a page that's not a subpage, that's a lot more interesting, and please post your exmples here. RoySmith (talk) 19:28, 24 February 2024 (UTC)

That is incorrect. The breadcrumb links have nothing to do with this. It's happening on pages where Special:PrefixIndex is transcluded, usually via templates like {{Featured article tools}} and {{SPI archive notice}}. Nardog (talk) 19:43, 24 February 2024 (UTC)

Oh, I thought the back links also called PrefixIndex. In any case, thank you for the correction. RoySmith (talk) 19:49, 24 February 2024 (UTC)

Theme switching back and forth

I use the Vector 2010 theme, but have noticed that on a few AfD pages it switches to some sort of different, worse, minimalist theme. When I click "switch to old look" it takes me to the user page where it shows I am using the old look. Most pages are fine including this one. Is this a bug? SportingFlyer T·C 22:32, 24 February 2024 (UTC)

Yes. See above. * Pppery * _{it has begun...} 22:35, 24 February 2024 (UTC)

Thanks! I absolutely detest Vector 2022 - anything I can do to help? SportingFlyer T·C 14:28, 25 February 2024 (UTC)

Skin changing

Beginning yesterday, whenever I visit a page starting with the prefix Wikipedia:Featured article candidates/, the page is displayed in Vector 2022 (I think?). Every other page, and those pages in edit mode, display in the skin I have set, which is not that. Anyone know what is causing that? Nikkimaria (talk) 02:33, 26 February 2024 (UTC)

Same issue for me and the FAC I have open at the moment. Very annoying - looks like it's a bug that will hopefully get fixed soon. PCN02WPS (talk | contribs) 05:01, 26 February 2024 (UTC)

Status

I've just been chatting with some of the WMF RelEng folks on IRC. I don't want to speak for them, but I will say that they're aware of the problem and working on it. The best thing for most of us to do at this point is to let them do their thing and watch T336504 for status updates. It looks like doing a hard reload (hold down the shift key while reloading in Chrome; I assume soemthing similar on other browsers) gets you back to your configured skin, so in the meantime, that's a viable workaround. RoySmith (talk) 15:35, 26 February 2024 (UTC)

Unfortunately such refresh options are not available on mobile, and even clearing all site data for Wikipedia doesn't clear the issue from all pages. -- LCU ActivelyDisinterested «@» °∆t° 22:35, 26 February 2024 (UTC)

Sadness. RoySmith (talk) 22:39, 26 February 2024 (UTC)

ActivelyDisinterested, in Firefox for Android, a long tap on the reload button is a hard reload. —⁠andrybak (talk) 12:44, 2 March 2024 (UTC)

Unfortunately not the same in Chrome. -- LCU ActivelyDisinterested «@» °∆t° 16:09, 2 March 2024 (UTC)

Resolved?

This is no longer happening for me, so I think it's been resolved. Can anyone else confirm? NW1223<Howl at me•My hunts> 18:56, 27 February 2024 (UTC)

Yes, the fix has been deployed yesterday (or this morning, depending on your time zone: phab:T336504#9579650). Matma Rex talk 23:19, 27 February 2024 (UTC)

Every link I check is working correctly now, thanks to all involved. -- LCU ActivelyDisinterested «@» °∆t° 16:12, 2 March 2024 (UTC)

Sticky header template for tables. Need iphone and Android testers

Note: Looking for an iphone user with a bigger screen than iphone SE 2020 or iphone 6s.

Concerning sticky headers on tables. See this popular template, and new testcase styles discussion:

• Template:Sticky header
• Template talk:Sticky header#Template improvements

The opinions of more experts would be greatly appreciated concerning any possible improvements.

This is a template I started, and has been improved by Jroberson108. Some tests are being run, but I am the only iphone user doing the tests, and Jroberson108 is the only Android phone user doing the tests so far.

We need other cell phone users to look at the sandbox pages in their cell phones in both portrait and landscape orientation. The current template styles work very well now for iphone users (at least for me using iphone SE 2020 in mobile Safari, Firefox, Edge, Chrome, Opera) no matter the width of the table. In both portrait and landscape view. I do not need to zoom out, or change the font size.

I am worried that there may be less iphone users able to see sticky headers on tables with these new styles. Because some of the new styles are specific to my iphone SE 2020. So I would like some other iphone users to compare the results of the old and new styles:

• Template:Sticky header - current styles.
• User:Timeshifter/Sandbox244 - current styles. More tests and table widths.
• User:Timeshifter/Sandbox243 - testcase styles. More tests and table widths.
• User:Timeshifter/Sandbox245 - testcase styles. Narrow 3-column tables only.
• Template:Sticky header/testcases - testcase styles. Intro may be incorrect since changes have been made. Not as many table widths.

I would also like some other Android phone users to look also. And tell us if the new styles are better or worse in portrait and landscape views. Specifically, one should not have to zoom or change font size to see sticky headers. But it may be required. Table widths shouldn't matter either. But they may. Be specific when comparing the old and new styles.

The main effect of the new styles is to allow non-sortable tables to have sticky headers on desktop and cell phones. But that was never a big problem because it is easy to add class=sortable to a table. And {{sort under}} if necessary.

If the new styles affect iphone and Android phone users positively, then the new styles should go live. But if they are negatively effected by the new styles, then the new styles need to be improved. And advice from experts is requested in any case. --Timeshifter (talk) 13:40, 26 February 2024 (UTC)

I don't have time to read through the (extensive) discussion on the template pages, but here are my observations (appropriately displayed in a table):

	sandbox244 (old)	sandboxen243 & 245 (new)
Firefox Desktop	Only sortable tables have sticky headers	All headers are properly sticky
Firefox Android	Only sticky if the table is sortable and I (pinch) zoom out so the full width of all tables is visible (because apparently those don't scroll horizontally?)	None sticky in portrait, all sticky in landscape

My viewport is 396px wide in portrait, and 760px wide in landscape. (...which is really weird scaling, because the physical display is 1080x2340. Huh.) Hopefully that's of some help. LittlePuppers (talk) 23:10, 26 February 2024 (UTC)

@LittlePuppers: I have the same experience on my Android. Jroberson108 (talk) 23:32, 26 February 2024 (UTC)

LittlePuppers. Thanks! Am I correct to assume that all table widths worked in Firefox Android landscape without zooming? Were any of the tables wider than landscape view? I just added some columns to a couple wide tables to make them into really wide 12 or 13-column tables. Here: User:Timeshifter/Sandbox243. --Timeshifter (talk) 00:23, 27 February 2024 (UTC)

User:Timeshifter/Sandbox243#Test sticky-header (sortable) is the only one wider on my Android Chrome landscape where I have to zoom out to make it sticky. It pushes beyond the main content area making the whole page wider, but the text is still readable. Without zooming, the edge of the screen ends inside header 9. "Test sticky-header (no caption)" too, which the edge ends inside header 12. Jroberson108 (talk) 01:15, 27 February 2024 (UTC)

Thanks. I just increased that one to 13 columns. I created some 12 or 13-column tables for the current styles too: User:Timeshifter/Sandbox244. Does the sortable table there require zooming to be sticky in landscape? --Timeshifter (talk) 01:47, 27 February 2024 (UTC)

It appears that with either version of the template (old or new), if there is any table on the page wider than the default width, no headers will be sticky until the page is zoomed all the way out. LittlePuppers (talk) 02:03, 27 February 2024 (UTC)

I agree, for User:Timeshifter/Sandbox243 in landscape you have to zoom all the way out for a table to be sticky. Also, if all the sections are open (all tables in view), then no tables are sticky unless you zoom all the way out.

For User:Timeshifter/Sandbox244, nothing is sticky except "Test sticky-header (sortable)", which requires zooming out to be sticky. Jroberson108 (talk) 02:24, 27 February 2024 (UTC)

I am still looking for an iphone user to look at this. TheDJ, I vaguely remember you having an iphone. And you created the sticky header gadget:

• MediaWiki:Gadget-StickyTableHeaders.css
• MediaWiki:Gadget-StickyTableHeaders.js
• Special:Preferences#mw-prefsection-gadgets

--Timeshifter (talk) 14:32, 27 February 2024 (UTC)

I have a very busy week, I can't make any promises until the weekend. —TheDJ (talk • contribs) 10:04, 28 February 2024 (UTC)

OK. Just bumping this to keep it out of the archives. --Timeshifter (talk) 00:01, 3 March 2024 (UTC)

They seem to work fine on my iPhone 6s in Safari and Chrome. —Compassionate727 ^(T·C) 20:28, 3 March 2024 (UTC)

Compassionate727. Thanks! Did you check the the old and new styles by checking sandboxes 244 (old) and 243 (new)? It is the comparison that we need the most. Do you see sticky headers on the widest sortable tables without having to do anything special? On both sandboxes? --Timeshifter (talk) 21:24, 3 March 2024 (UTC)

Erm, I only looked at 243. I looked at 244 just now and the headers are not sticky. (I thought that was expected?) The width of the table doesn't affect anything beyond the fact that I have a small screen and wide tables are inherently less readable anyway. —Compassionate727 ^(T·C) 00:12, 4 March 2024 (UTC)

Compassionate727. Thanks again. It looks like your iphone 6s screen and viewport is the exact same size as my iphone SE 2020 screen and viewport:

• https://yesviz.com/iphones.php
• IPhone#Models

I fixed something on sandbox 244. Could you look again at the wide sortable table here:

• User:Timeshifter/Sandbox244#Test sticky-header (sortable)
• User:Timeshifter/Sandbox243#Test sticky-header (sortable)

On my iphone in Safari, Firefox, Chrome, Edge, and Opera: The wide sortable table is sticky in sandbox 243 and sandbox 244. --Timeshifter (talk) 12:57, 4 March 2024 (UTC)

Sticky headers work in those sections in Chrome and Safari. In fact, they work in every section in sandbox 243, but not 244; in sandbox 244, all of the tables in sections 1, 2, 3, 7, and 8 are NOT sticky in both Safari and Chrome. —Compassionate727 ^(T·C) 21:12, 4 March 2024 (UTC)

Thanks Compassionate727 for the full review of all sections! The current CSS does not work on non-sortable tables. Those are the sections in 244 that are not working for you. I get the exact same results as you.

I am wondering if only users with small iphones get such good results. The testcase CSS is specifically pointed at iphones with the smaller viewport size found in iphone 6, 6s, 7, 8, SE 2020, and SE 2022. They all have the exact same screen size and viewport size. See:

https://yesviz.com/iphones.php

--Timeshifter (talk) 22:08, 4 March 2024 (UTC)

I don't see any reason not to go live with the new styles. No issues have been found. If there are issues, then editors can simply bring it up on the talk page. Jroberson108 (talk) 07:02, 5 March 2024 (UTC)

As I stated before, if the current styles work perfectly (for sortable tables) on all iphones, but only for smaller iphones with the proposed styles, then the new styles are not a net improvement. In that case the new styles only help with nonsortable tables. Nonsortable tables were not a serious problem in comparison. Because it is easy to make a table sortable. And sortable in a way that does not make the table wider (via {{sort under}}). Plus the new styles would break some of the tables; those with multiple header rows. We would have to go back and change the class on those tables from class=sticky-header to class=sticky-header-multi. So let's just relax and wait for some later iphone model users to show up. If the new styles work for them, then the new styles are a net benefit, and I would support them. --Timeshifter (talk) 13:00, 5 March 2024 (UTC)

Well, FWIW, they work properly when I switch to mobile view on my laptop. Presumably if they work on both the smallest phone screen and a computer screen, they'll work on anything in between? —Compassionate727 ^(T·C) 15:04, 5 March 2024 (UTC)

What brand and model is your laptop? It is possible to switch to mobile view from a desktop PC too. Link is at the bottom of all Wikipedia pages. But I don't think it gets the same results as the mobile view on a cell phone. I vaguely remember that problems ensued when I tried this method before. --Timeshifter (talk) 15:16, 5 March 2024 (UTC)

And if they don't, then editors can easily mention it on the talk page like any normal issue, which these changes are additive. It's not a big deal. If the old styles are kept, then the same mobile fixes would need to be applied to fix Android issues, so comparing them like this is nonsensical. Also, mobile isn't the only fix, so I wouldn't get hung up on it. Jroberson108 (talk) 15:17, 5 March 2024 (UTC)

Apparently, there is no improvement for Android sortable tables. LittlePuppers wrote: "It appears that with either version of the template (old or new), if there is any table on the page wider than the default width, no headers will be sticky until the page is zoomed all the way out." You agreed with LittlePuppers.

We are not sure if there is any improvement for sortable tables on most iphones. We don't know whether sortable tables are sticky on most iphones (those larger than my small one) on both the current or proposed styles. --Timeshifter (talk) 15:36, 5 March 2024 (UTC)

It seems like you don't understand the Android issues either. When tables are sticky on Android, horizontal scroll on wide tables don't work. LittlePuppers and I have both said this. Minerva adds horizontal scrolling to tables for an improved mobile experience on small screens, which occurs at Minerva's device break point (width <=720px). On Android, sticky breaks that preexisting feature making the experience worse and causes a readability issue when zooming out. It's not a matter of "no improvement", but "worse". This may be the case on other non iPhones. You mentioned that horizontal scroll still works on your iPhone, so exceptions were added for Minerva's small screens. You wanting every iPhone model in existence to test this is ridiculous. Again, if there are other issues, then it can be mentioned on the template's talk page and those changes would be additive. Jroberson108 (talk) 16:08, 5 March 2024 (UTC)

I only want to see what is happening on any iphone larger than mine. Which is most iphones. --Timeshifter (talk) 16:23, 5 March 2024 (UTC)

Request for comment from other iphone users

I am looking for iphone user(s) with a bigger screen than iphone SE 2020 or iphone 6s. I am not sure if the current CSS, or the testcase CSS, works on bigger iphones at all. Or if it does work, how well it is working. Because some of the CSS is specific to my iphone viewport. See previous discussion. This is not a voting RFC. This is just another attempt to get some input from other iphone users. I left a message awhile back at the computing reference desk, but no one showed up here from it. --Timeshifter (talk) 13:22, 4 March 2024 (UTC)

@Timeshifter: Why on earth do you think that a full-blown thirty-day formal WP:RFC is the best means of gaining the attention of iPhone users? --Redrose64 🌹 (talk) 09:06, 5 March 2024 (UTC)

I have seem many RFCs that lasted less than a week. I already tried getting more iphone users a couple other ways. I just asked for help at Help:Desk. Iphone users: To make this as simple as possible please tell us if sticky headers work without problems in this section:

• Current styles: User:Timeshifter/Sandbox244#Test sticky-header (sortable)
• Proposed styles: User:Timeshifter/Sandbox243#Test sticky-header (sortable)

And tell us what iphone model you have. --Timeshifter (talk) 13:14, 5 March 2024 (UTC)

@Timeshifter Tldr, tested both testcases on 14 Pro Max is working. — Paper9oll (🔔 • 📝) 06:26, 7 March 2024 (UTC)

Thanks Paper9oll! So those wide tables had sticky headers in that specific sandbox section in both sandboxes? In both portrait and landscape orientation on your iphone?

Tldr is fine, because those 2 sandbox sections are all I am concerned about right now. --Timeshifter (talk) 12:34, 7 March 2024 (UTC)

@Timeshifter For portrait, both sandboxes is working. For landscape, only the first sandbox is working. — Paper9oll (🔔 • 📝) 12:47, 7 March 2024 (UTC)

Paper9oll. "For landscape, only the first sandbox is working." Are you referring to sandbox244? --Timeshifter (talk) 13:05, 7 March 2024 (UTC)

@Timeshifter Yes — Paper9oll (🔔 • 📝) 13:46, 7 March 2024 (UTC)

Thanks again Paper9oll. Well, that's too bad. That means that the proposed styles are a step backwards for most iphones. I (with my smaller iphone) see the same thing you are seeing with the current styles for sortable tables (that section in sandbox244). With the current styles I see sticky headers working perfectly in sortable tables in landscape and portrait view no matter the width of the table (that section in sandbox244).

Most iphones in use nowadays are bigger than my smaller iphone SE 2020.

For sortable tables the proposed styles work the same as the current styles for my smaller iphone. This is because the proposed styles address my specific smaller viewport size. --Timeshifter (talk) 14:12, 7 March 2024 (UTC)

What about "addditive" do you not comprehend? Jroberson108 (talk) 14:31, 7 March 2024 (UTC)

What about "patience" do you not comprehend? You are approaching WP:NPA and WP:TALK problems again in your passive aggressive tone. Please remain collegial in our discussions. What's the rush? Why go backward in some areas if it is not necessary? If you truly believe that you or someone else will figure out a solution for all iphones soon, then we can wait. If it is going to take months or years to improve, as it did in the past with sticky headers, then that is even more reason to wait. It is easy to make tables sortable. I did it several times in order to use the sticky headers template. And {{sort under}} makes it possible to do so without increasing table width. So right now, nothing is really "broken" with the current styles in any serious way. --Timeshifter (talk) 14:41, 7 March 2024 (UTC)

@Paper9oll: For the page and orientation that's not sticky, can you provide the width and height from https://whatismyviewport.com/? Just the large font, not the rest. If you use multiple browsers, can you provide them for each if they differ. Jroberson108 (talk) 14:28, 7 March 2024 (UTC)

@Jroberson108 Portrait is 375x630px and landscape is 710x292px. Browser is iOS default browser (Safari). — Paper9oll (🔔 • 📝) 14:36, 7 March 2024 (UTC)

@Paper9oll:, can you test the one that wasn't sticky again? Jroberson108 (talk) 14:50, 7 March 2024 (UTC)

@Jroberson108 Both are working now in both orientation. — Paper9oll (🔔 • 📝) 15:19, 7 March 2024 (UTC)

@Paper9oll: Thanks. It just needed an exception added. Jroberson108 (talk) 15:36, 7 March 2024 (UTC)

I have been trying to wrap my brain around those exceptions in the proposed CSS:

screen and (width: 710px) and (orientation: landscape),
screen and (width: 667px) and (orientation: landscape),
screen and (width: 375px) and (orientation: portrait)

The pattern is obvious for my iphone SE 2020 (375x667px). See my viewport listed here:

• https://yesviz.com/iphones.php

I suggest substituting this for the iphone 14 Pro Max:

screen and (width: 932px) and (orientation: landscape) 

If it works, then exceptions could easily be added for all iphones. By using the page linked just above. ---Timeshifter (talk) 20:07, 7 March 2024 (UTC)

I wish it were that easy, but they gave their landscape viewport width as 710px and their test worked. No exceptions are needed for a width over 720px, so a width of 932px is already covered and redundant. If you recall, your iPhone viewport height was different from the listing too. Multiple browsers were a bit different in viewport height, but the width was consistent. Jroberson108 (talk) 20:59, 7 March 2024 (UTC)

So this block resets the mobile table's BACK from scrollable blocks to normal tables... in orientation mode for very specific widths ... I don't get why.. why not for all widths over portrait phone sizes ? What would break on my much larger desktop screen ? I'm confused. —TheDJ (talk • contribs) 22:19, 7 March 2024 (UTC)

@TheDJ: No issues on desktop. Basically overriding Minera's device breakpoint of <= 720px causes issues on Android and maybe some other untested devices. The issue is that the table's horizontal scroll doesn't work when sticky, which a wide table pushes beyond the main content area making the page wider, and requires zooming out to see the entire table before it's sticky making the text on the entire page more unreadable the wider the table is.

Apparently this same issue doesn't occur on iPhone since the horizontal scroll works. The code Timeshifter posted comes from the sandbox (see comments) at the bottom and is an attempt to get it working on only iPhone at that break point, which I know widths alone aren't enough to target only iPhone, but its all we have since he wants it working. Fixing horizontal scroll on Android would be ideal, but the only solution I've found is moving the horizontal scroll to a div wrapper, which isn't possible with this template. The div wrapper solution is something I did on the COVID sticky styles that you helped fix. Jroberson108 (talk) 23:16, 7 March 2024 (UTC)

@TheDJ: I created User:Timeshifter/Sandbox246 so I could test your sticky gadget found in gadget preferences. The sandbox has no sticky templates. On my Win 10 Pro desktop in Firefox your gadget worked on all tables there regardless of width (including the 16 column table). Except it did not work with nonsortable plain tables. It worked with sortable plain tables. And it worked with nonsortable wikitables. On my iphone it did not work in that sandbox in Safari and Firefox. In both portrait and landscape view. --Timeshifter (talk) 23:39, 7 March 2024 (UTC)

@Paper9oll: Could you check another browser besides Safari? What is its viewport here:

• https://whatismyviewport.com

And are the tables sticky in sandboxes 243 and 244 in landscape and portrait view? Maybe like with my iphone SE 2020 the landscape viewport width stays the same across browsers.

Your screen size (6.7 inches) is the largest size iphone screen size. So we would need viewport sizes for all iphones. I count 10 different iphone viewport sizes here (sort that column):

• https://yesviz.com/iphones.php

That must be the viewport size not counting the navigation bars.

I wish there was a page listing the actual viewport sizes with the navigation bars. --Timeshifter (talk) 22:40, 7 March 2024 (UTC)

@Timeshifter Please see below.

Safari

• 375x630px (portrait)
• 710x292px (landscape)

Working for both sandboxes in both orientation.

Chrome

• 375x636px (portrait)
• 710x319px (landscape)

Working for both sandboxes in portrait. Not working for Sandbox243 in landscape.

Firefox

• 375x609px (portrait)
• 710x279px (landscape)

Working for both sandboxes in both orientation.

Edge

• 375x644px (portrait)
• 812x306px (landscape)

Working for both sandboxes in portrait. Not working for both sandboxes in landscape, would autojump to end of page when scrolling through each tables.

Brave

• 375x626px (portrait)
• 710x294px (landscape)

Working for both sandboxes in both orientation.

— Paper9oll (🔔 • 📝) 09:12, 8 March 2024 (UTC)

Thanks Paper9oll for that thorough report! I wonder why Chrome did not work in landscape in sandbox243? The viewport width is the same as the others.

And in Edge did it work for narrow tables in either sandbox in landscape? Please close all the sections, and then go to a section with narrow tables. We have seen this sometimes where any visible table wider than the screen causes all tables not to have sticky headers (even narrow tables on the same page).

These 2 sandboxes only have very narrow tables:

User:Timeshifter/Sandbox245 - Proposed styles.

User:Timeshifter/Sandbox247 - Current styles.

--Timeshifter (talk) 16:49, 8 March 2024 (UTC)

@Paper9oll: Thanks for the extensive testing. Edge landscape seems to be doing some weird stuff like maximizing the use of the landscape viewport area or something, so I can't speak to that. The Chrome landscape result does seem odd since it's also 710px.

Making it so Android still has horizontal scroll on tables and sticky works on iPhone for Minerva width <= 720px is becoming increasingly difficult. Ideally, the Android horizontal scroll should be fixed if possible so targeting only iOS isn't needed.

Maybe TheDJ will be able to figure out a fix for the horizontal scroll or an easier way to target only iOS perhaps with a combination of @supports (-webkit-touch-callout: none), @query, and other -webkit styles? Maybe there is a class that MediaWiki adds to the html or body element to identify iOS that I'm unaware of?

Doesn't seem like TheDJ has the time right now, so Timeshifter it seems like your only blocker is the new styles not working on 100% of the iPhones. I can modify it so it works on all iPhones and the Android issue persists just as it does on the live styles. This way the rest of the fixes and improvements can move along. Hopefully this satisfies everyone and TheDJ can find the time one day to fix the rest. Jroberson108 (talk) 02:49, 9 March 2024 (UTC)

I prefer to wait until the other 8 iphone viewport sizes are sticky in the proposed styles. I don't want to go backward on iphone sticky tables. Right now with the current styles they are working amazingly well. Considering how difficult it has been to get people with 2 iphone screen sizes (4.7 inch and 6.7 inch), it could take months to find people with the other 6 screen sizes, and 8 viewport sizes. As I wrote before I count 10 different iphone viewport sizes here (sort that column):

https://yesviz.com/iphones.php - and 8 screen sizes (a different column).

Maybe while looking for them someone figures out another solution. I think maybe we should keep the current styles, and you and/or others can concentrate solely on Android. And not worry about nonsortable tables at all. I think Android tables being sticky without problems is far more important. If we end up with Android and iphones being sticky without problems, but we can't combine that with nonsortable tables, then I am still very happy with that. It would be a great improvement. --Timeshifter (talk) 04:46, 9 March 2024 (UTC)

@Timeshifter As requested, Sandbox245 and Sandbox247 is working on both Chrome and Edge in both orientation with no issues. @Jroberson108 As for Chrome, I forgot to mention that on Sandbox244 and Sandbox243, in landscape, it will autozoom out to fit the entire table into the screen itself as if I'm viewing it in Wikipedia's desktop view hence maybe that explain why despite having same 710px as Safari which doesn't do autozoom out to fit. — Paper9oll (🔔 • 📝) 06:43, 9 March 2024 (UTC)

@Paper9oll: Yeah, sounds like the Chrome width changes, but you can't get the width value on the other site since it's content isn't wider than the screen. To make matters worse, that width would vary based on how wide the table is when the autozoom out happens. Jroberson108 (talk) 07:41, 9 March 2024 (UTC)

@Timeshifter: I'm not sure what you mean by "backward on iphone sticky tables"? The change I propose on the sandbox styles is to make sticky work on all iPhones without having to add viewport widths for each device. The Android horizontal scroll issue would still exist. This part would work just like the current (live) styles, so all iPhones remain sticky.

I'm not abandoning the fix for Android, just removing it as a blocker so the other fixes and improvements can go live. The Android fix can still be worked on and added at a later time once fixed. I'm still hoping TheDJ or someone else might have a better fix that doesn't involve device widths, whether it be now or later. But, the other parts of the sandbox styles don't depend on the Android fix. Jroberson108 (talk) 07:25, 9 March 2024 (UTC)

@Timeshifter: I updated the sandbox styles so you can see what I'm talking about. The new styles should work on all iPhones now without needing to add viewport widths specific to devices. The same way it works on the current (live) styles. Fixing the Android horizontal scroll issue, which the issue also exists on the current (live) styles, is a secondary task. The sandbox styles can now replace the current styles. The Android fix can still be worked on separate from the rest of the styles whether it be adding the device widths back and continuing with that or some other solution. Please test and let me know if it works. Jroberson108 (talk) 14:12, 9 March 2024 (UTC)

Testing proposed styles #2

Jroberson108 and Paper9oll. I cleared the cache of all 5 browsers on my iphone SE 2020: Safari, Edge, Firefox, Opera, and Chrome. See:

• https://www.google.com/search?q=cache+clearing+on+iphone+browsers - I have it summarized on a card I keep handy.

At User:Timeshifter/Sandbox243 the proposed styles #2 work amazingly well. All tables are sticky no matter the width. Whether in portrait or landscape orientation.

Class=sorttop is not a problem except with class=sticky-header-multi (same as the first proposed styles). This is true for both wikitable or plain table. The table is still sticky no matter the width. But the sorttop rows with that class are sticky after sorting.

@Paper9oll: Can you test in all browsers too? If you get the same results, then this is an improvement over the current styles since it works with nonsortable tables too. And so I would support going live with it.

Jroberson108 and LittlePuppers. Are your Android phones better or worse with proposed styles #2 compared to the current styles: User:Timeshifter/Sandbox244? --Timeshifter (talk) 16:04, 9 March 2024 (UTC)

I agree that sorttop is a known issue on the current and sandbox styles, and not something fixable (it has a bug report). On Windows and Android, more things work and are sticky. On Android, the table's missing horizontal scroll and having to zoom out on wide tables for sticky to work is the same on the current and sandbox styles, so no change, as expected. No zooming out is needed if the only table that's visible is narrow and fits the portrait width like in "Test sticky-header (sortable). Narrower tables", so font size is unchanged and remains readable when sticky, which is the same in both. Jroberson108 (talk) 16:30, 9 March 2024 (UTC)

Excessive indentation of block quotations

I've noticed in recent weeks that <blockquote> elements have gained additional indentation, which is a terrible waste of space:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

{{quote}} doesn't have this issue, even though it uses <blockquote> internally:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

This might only be on mobile, I haven't checked on desktop. Hairy Dude (talk) 11:46, 3 March 2024 (UTC)

Hairy Dude, those appear identical to me, on desktop. — Qwerfjkltalk 11:50, 3 March 2024 (UTC)

Your screenshot shows they're not identical; the first has larger vertical margins. And Hairy Dude specifically said it's about the mobile interface. Nardog (talk) 11:53, 3 March 2024 (UTC)

So it does, 8px of padding apparently. — Qwerfjkltalk 11:56, 3 March 2024 (UTC)

I tried to fiddle with {{Blockquote/styles.css}} to make the two renderings match, but it looks like I am doomed to never understand how CSS works. In any event, the OP wants less vertical space, not more, so that wouldn't really be a good fix. The MediaWiki developers have been messing with vertical space between elements recently, which might have something to do with this discrepancy. See T358921 and its predecessors. It appears that every time they change something, there are undesirable side effects. Their suite of test cases is probably not extensive enough. – Jonesey95 (talk) 16:19, 3 March 2024 (UTC)

the OP wants less vertical space That's clearly not what he wants, if you read his last paragraph. Nardog (talk) 00:20, 5 March 2024 (UTC)

What skin are you using? Izno (talk) 17:51, 3 March 2024 (UTC)

Presumably Minerva. — Qwerfjkltalk 18:25, 3 March 2024 (UTC)

I'm seeing excess vertical space around the tag version in Vector 2022. Using the Inspector verifies that <blockquote>...</blockquote> uses .mw-body blockquote, applying padding: 8px 32px; in the tag-only section, while the template applies padding: 0 32px; to .mw-parser-output .templatequote to the same tag. – Jonesey95 (talk) 18:50, 3 March 2024 (UTC)

If it's mobile, it's probably the same cause as T357742. DLynch (WMF) (talk) 17:50, 4 March 2024 (UTC)

Toolforge tool/bot to send email notifications

Tracked in Phabricator
Task T356984

Tracked in Phabricator
Task T358087

As initially discussed here (and at phab) the ability for bot edits to trigger watchlist notifications via email has been disabled. The only suggestion provided (i.e. "we're not going to undo this") has been to create a toolforge tool to trigger these notifications. I do not have the knowledge or expertise to do so, hence a request for someone to do so, with (as suggested) the ability for users to input their watchlist key to trigger the tool. (please do not ping on reply) Primefac (talk) 12:11, 4 March 2024 (UTC)

And for what it's worth, I get why this was done, my parentheticals are more cheeky commentary than anything truly negative. Primefac (talk) 12:20, 4 March 2024 (UTC)

Just checking - your ask involves: (a) giving someone else your private watchlist token, and likely also your email address (b) have them watch your watchlist for you (c) have them send you emails about your watchlist changes? (And have them do this via a program that they will write, maintain, and operate - possibly with some screening/flood parameters)? — xaosflux ^Talk 10:38, 5 March 2024 (UTC)

FWIW a COTS RSS->EMAIL service may be able to accomplish what you want via Wikipedia:Syndication#Watchlist feed with token — xaosflux ^Talk 10:49, 5 March 2024 (UTC)

Oh, so I can give someone else my watchlist token that isn't even involved with Wikipedia... Primefac (talk) 12:33, 5 March 2024 (UTC)

Unfortunately, yes. There are some commercial services that do that - so the benefit would be that it could be ready to go and likely has ongoing support. — xaosflux ^Talk 14:05, 5 March 2024 (UTC)

Yes, that is exactly what was suggested. In the meantime, I suggested creating a tool in toolforge to do the work for you, you could potentially create a generalized one that users could "sign up" by providing their watchlist token. So one person would need to create and maintain the tool and others could just use it (and don't need to re-invent the wheel). Please don't insinuate that I am being unreasonable when I am simply asking for what I was told to ask for. Primefac (talk) 12:33, 5 March 2024 (UTC)

I don't think you have an unreasonable ask, just trying to outline all of the components for anyone that wants to take this up. For example, filtering parameters may be useful if you still want to use on-wiki email relay for non-bot flagged items. — xaosflux ^Talk 14:07, 5 March 2024 (UTC)

Fair enough, my apologies for the tone. Primefac (talk) 14:15, 5 March 2024 (UTC)

As an short-term solution, you could use the PageProbe extension in Firefox, or try to find something similar. The main problem with it is that it can not deal with an full watchlist, if something goes off your watchlist while you have not taken a look it is gone. It can check the watchlist however often you want (do not go under 10 seconds). You right click the first item in your watchlist, select "track content" and edit the tracker to your liking. It takes some time to get right, but works on it's own when you are satisfied with it. It will show up with it's icon and the number 1 when your watchlist has updated. The extension will only check your watchlist while your browser window is open and your computer on. Once your watchlist is updated open both the extension to clear the counter and your watchlist. Snævar (talk) 22:06, 5 March 2024 (UTC)

Tech News: 2024-10

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

Recent changes

• The Special:Book page (as well as the associated "Create a book" functionality) provided by the old Collection extension has been removed from all Wikisource wikis, as it was broken. This does not affect the ability to download normal books, which is provided by the Wikisource extension. [1]
• Wikitech now uses the next-generation Parsoid wikitext parser by default to generate all pages in the Talk namespace. Report any problems on the Known Issues discussion page. You can use the ParserMigration extension to control the use of Parsoid; see the ParserMigration help documentation for more details.
• Maintenance on etherpad is completed. If you encounter any issues, please indicate in this ticket.
• Gadgets allow interface admins to create custom features with CSS and JavaScript. The Gadget and Gadget_definition namespaces and gadgets-definition-edit user right were reserved for an experiment in 2015, but were never used. These were visible on Special:Search and Special:ListGroupRights. The unused namespaces and user rights are now removed. No pages are moved, and no changes need to be made. [2]
• A usability improvement to the "Add a citation" in Wikipedia workflow has been made, the insert button was moved to the popup header. [3]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 March. It will be on non-Wikipedia wikis and some Wikipedias from 6 March. It will be on all wikis from 7 March (calendar). [4][5]

Future changes

• All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [6]
• The HTML markup of headings and section edit links will be changed later this year to improve accessibility. See Heading HTML changes for details. The new markup will be the same as in the new Parsoid wikitext parser. You can test your gadget or stylesheet with the new markup if you add ?useparsoid=1 to your URL (more info) or turn on Parsoid read views in your user options (more info).

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

MediaWiki message delivery 19:45, 4 March 2024 (UTC)

What makes Visual Editor not generate ref names?

I've started using User talk:Nardog/RefRenamer, but it only works on refs that already have names. Surprisingly, many of mine don't. For example, in Special:Diff/1209797986, I used VE to add a ref, but the generated ref tag didn't get a name=":n" attribute. What did I do to VE to make it not like me? RoySmith (talk) 15:45, 5 March 2024 (UTC)

RefRenamer is a great/fun tool (though I wonder how much churn it will create as users continue to re rename based on personal preference). To your point, the example Diff has only a single instance. Generally it's a good idea not to use ref names when there is no reason. Wait for future editors if they need it (in most cases they never will). One might say you are being prepared, but really it clutters the article, adds complexity, and is one more thing to deal with (name conflicts etc). In fact, RefRenamer even defaults to removing ref names that are singular. There might be a rule or guideline somewhere. As for VE, I don't know, maybe it's built-in to not add ref names for single refs. -- GreenC 16:01, 5 March 2024 (UTC)

VE developers didn't spend any time on this issue at development. The only rationale I can ascertain was the general "source editing will be a thing of the past so we don't have to care about certain qualities", well-named references being one of those qualities. There was a community wishlist item on the point that scored highly that went nowhere. Izno (talk) 16:35, 5 March 2024 (UTC)

Why should it be named if it's used only once? Nardog (talk) 01:17, 6 March 2024 (UTC)

@RoySmith: Agree with Nardog; if it doesn't have one, it doesn't need one. That said, nobody is stopping you from optionally adding refnames directly to the citations. Also, iirc RefRenamer does permit you to add a name to a ref that is unnamed; it isn't the default option, but it allows you to add unnamed refs to the activity table from the list of other refs in the article, and from there you can supply a name. At least, that's what I recall. Mathglot (talk) 01:34, 6 March 2024 (UTC)

It does allow you to optionally rename refs whose names were not autogenerated, but it currently doesn't support adding names to refs that aren't named at all. Nardog (talk) 01:37, 6 March 2024 (UTC)

Articles without talk pages

There are over 100,000 mainspace articles without a talk page: 1857 Faroese general election. Is this normal/expected, or a breakdown in a process somewhere? I noticed it in my logs while running the bot reftalk. -- GreenC 16:04, 5 March 2024 (UTC)

@GreenC, I suspect the answer to your question is the same as your answer to my question about ref names: YAGNI :-) RoySmith (talk) 16:09, 5 March 2024 (UTC)

GreenC, I think my bot is approved to create them, if that would be desirable. — Qwerfjkltalk 16:36, 5 March 2024 (UTC)

• There's isn't anything inherently wrong with non-existent discussion pages. — xaosflux ^Talk 16:44, 5 March 2024 (UTC)

I would support adding talk pages where they don't exist. Especially if you also set it up with archiving set to the default setting of 4 talk sections minimum before archiving. Many editors are hesitant to start a talk page, and even more are hesitant to set up talk archiving. Or completely unable to do so due to lack of knowledge and time. --Timeshifter (talk) 16:53, 5 March 2024 (UTC)

Only 100,000 out of six million? That seems pretty good. I think Ser Amantio di Nicolao creates talk pages as a hobby. They might have something to contribute here. – Jonesey95 (talk) 17:17, 5 March 2024 (UTC)

Way back at the dawn of time (ten or eleven years ago, if not a bit more), I believe there was at least an unofficial policy of creating talk pages for all articles for which they did not exist, with one or two WikiProject templates if nothing else. This would get the articles onto the radar of one or two projects interested enough in the subject to take a look and refine what was there. I did a lot then, and so did a handful of other editors (Dr. Blofeld springs to mind, for one). I think it's still a useful task, though I don't know how active many WikiProjects are any more compared to where they used to be. --Ser Amantio di Nicolao^{Che dicono a Signa?}_{Lo dicono a Signa.} 17:22, 5 March 2024 (UTC)

My YAGNI comment above notwithstanding, I think @Timeshifter makes an excellent point. We encourage editors to discuss things on the talk pages so we should be working to remove any barriers to that happening. RoySmith (talk) 17:23, 5 March 2024 (UTC)

The redlink for the talk page on 1857 Faroese general election takes you to page with a "Start a discussion" button so I assume the page is automatically created when someone does. No real barrier there. Creating talk pages is useful for adding projects and importance ratings and there are people who routinely do this for the Tree of Life project. I suppose the 100,000 articles without talk pages don't have an obvious home in an active project. —  Jts1882 | talk  17:50, 5 March 2024 (UTC)

When you're a newbie, everything that doesn't work exactly as you expected, or has an extra step, is a barrier to entry. RoySmith (talk) 17:59, 5 March 2024 (UTC)

I'd say the page with "Start a discussion" button was easier to understand for a newbie than the talk page where they have to select "edit" or "+". —  Jts1882 | talk  18:11, 5 March 2024 (UTC)

Jts1882, I believe they will see an "Add topic" link. — Qwerfjkltalk 18:18, 5 March 2024 (UTC)

Jts1882. Before the talk page was started the red link took me directly to an edit window. But it did not have a spot for a talk section heading. So it is confusing. Not as easy as the "add topic" link that takes care of the equal signs for headings.

By the way does anyone here use an iphone? Please help with this template test:

#Request for comment from other iphone users

--Timeshifter (talk) 18:36, 5 March 2024 (UTC)

Jts1882, I suppose the 100,000 articles without talk pages don't have an obvious home in an active project. I doubt it, because I ran Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 19 on all the talk pages that were missing then. — Qwerfjkltalk 18:02, 5 March 2024 (UTC)

@Timeshifter It seems that you disabled the feature that shows a nice message on non-existing talk pages; try re-enabling it at Special:Preferences#mw-prefsection-editing-discussion (below "When I visit a discussion page that hasn't been created yet:") and see if you still think that they need to be created. Matma Rex talk 12:46, 6 March 2024 (UTC)

I don't have a problem creating new talk pages. I have been editing many years. I am more concerned with new editors. I just chose that preference. Just to see what it offers. Do you know of a non-existing talk page I can check? If it makes adding a new topic to a non-existing talk page simple, complete with a header line, then maybe that should be the default setting for all users, both logged in and not logged in. --Timeshifter (talk) 13:27, 6 March 2024 (UTC)

For an example, you can try at Talk:1859 Faroese general election (at least until someone creates it to make a point, like they did at Talk:1857 Faroese general election, which was given as an example earlier in this thread).

That preference is already the default for all users, you must have turned it off in the past. Matma Rex talk 13:57, 6 March 2024 (UTC)

Matma Rex. I remember now why I disabled it. It only provides a limited editing toolbar. Something I hate anywhere I see it: Mediawiki.org, Fandom community forums, etc.. If some editor wants to discuss tables or references, they can't do so with the first post on a talk page. The full functionality of the wikitext or Visual Editors are needed for that. It seems like some developers are always trying to sneak in these limited editing windows on all wikis. I sometimes don't use the "Add topic" editing window on talk pages, and here on the Village Pump, for the same reason. I start a new topic with the wikitext editor instead. So I think the full editing toolbar should be in that first post editing window. At least in the source tab. --Timeshifter (talk) 15:24, 6 March 2024 (UTC)

What about WP:TALK#CREATE which says "Do not create an empty talk page simply so that one will exist for future use." Johnuniq (talk) 00:28, 6 March 2024 (UTC)

It is just busywork (ie waste of time) creating talk pages with nothing but bannershell or talk page header. Only create them if you are going to add a project, or say something useful. Graeme Bartlett (talk) 00:36, 6 March 2024 (UTC)

There is no need to put anything on the talk page at first. A period will do for starting the talk page. It's not a waste of time if it helps encourage more discussion from newbies. WP:TALK#CREATE should be changed. Apparently, from this discussion, it was common in the past to start talk pages. --Timeshifter (talk) 01:32, 6 March 2024 (UTC)

Be careful what you wish for! To respond to a comment way above, many talk pages never have any threads, let alone enough to warrant archiving. Also see earlier comments in this thread that also mentioned articles without talk pages (and the links therein). Graham87 (talk) 03:22, 6 March 2024 (UTC)

I think a talk page should automatically be created when an article is started. Along with archiving being set up. It hurts nothing to have it set up. Since it is automatic it doesn't do anything until it is needed. I see so many talk pages with messed-up archiving, or none at all. I also think links to talk section headers should be permanent links that work even when the talk section header name is changed. Without having to set up anchors. --Timeshifter (talk) 03:46, 6 March 2024 (UTC)

"Since it is automatic it doesn't do anything until it is needed" Nope ... the bot has to check whether it needs archiving every day. Each check might not take that long in the grand scheme of things, but it would definitely add up over millions of pages that mostly wouldn't need archiving. Graham87 (talk) 06:26, 6 March 2024 (UTC)

I have seen various discussions about templates, substitution, bots, server load, etc.. And the developers have always said it was not a problem. And I don't see why an archiving bot would have to check every day. If server load ever became a problem (which I doubt), then the bot could be set to check only when the page is edited, and not more than once a day. --Timeshifter (talk) 12:10, 6 March 2024 (UTC)

The problem is that archiving bots are not run by MediaWiki. They are run by individual members of the community, and thus WP:DWAP does not apply. lowercase sigmabot III is run by Σ, who last edited 20 months ago. A feature to check only when the page was edited does not exist, and I doubt someone who last edited over a year ago is interested in setting that up. HouseBlaster (talk · he/him) 04:33, 7 March 2024 (UTC)

Also, I was curious: ClueBot III is currently set to archive 10,617 pages and lowercase sigmabot III is set up on 37,550. Given there are over six million articles, there is no way the bots can handle being set up on all of the pages. HouseBlaster (talk · he/him) 04:37, 7 March 2024 (UTC)

Thanks for Wikipedia:Don't worry about performance link. It says the opposite of what you are saying. It says that if there is a problem sysadmins will fix it. And that they have done it many times already. Regardless of whether the problem was at the system code level, or with templates edited by users. So, "Don't worry about performance". The Brion Vibber quotes are illustrative of the point. He was the chief sysadmin for awhile. And adding archiving to all talk pages would probably require developer help. So stop worrying. Or as Brion Vibber said (upper case letters are his, emphasis is mine): "I made a general recommendation not to go running around saying THE SKY IS FALLING THE SKY IS FALLING about templates BASED ON SUPPOSITION AND PARANOIA." --Timeshifter (talk) 13:48, 7 March 2024 (UTC)

Let me try again: we don't have to worry about performance of MediaWiki (the software that Wikipedia uses). The archiving bots are not part of MediaWiki. And if we were to do this, it would not require developer help. We would need to run a bot to add the code to all talk pages, which is trivial. HouseBlaster (talk · he/him) 17:10, 7 March 2024 (UTC)

Bruh moment. Every single day?! There isn't a way to specify that e.g. talk pages that haven't been edited in xyz days only get checked every week?? jp×g🗯️ 09:16, 7 March 2024 (UTC)

Nope. Graham87 (talk) 12:30, 7 March 2024 (UTC)

Maybe not currently. But there is no reason that the template couldn't be changed to check only when the talk page is edited, and not more than once a day. If it needed to be done due to server load, then developers would make sure it happened. According to WP:DWAP. See my reply to HouseBlaster higher up. --Timeshifter (talk) 13:53, 7 March 2024 (UTC)

It is not the template which would need to be changed, it is the bot. The template just tells the bot what to do, if that makes sense. HouseBlaster (talk · he/him) 17:20, 7 March 2024 (UTC)

The template just adds a backlink to the page, visable from WhatLinksHere. It doesn't "call" the bot to edit the page, as it were. — Qwerfjkltalk 17:35, 7 March 2024 (UTC)

According to WP:DWAP, however it is done (templates, bots, system code, etc.), the sysadmins can handle any problems with server loads. That's not our problem. They will intervene as necessary to fix problems. So we can add archiving to all talk pages now. --Timeshifter (talk) 18:50, 7 March 2024 (UTC)

Sysadmin intervention would probably consist of just blocking the bot, if it managed to cause problems with the stability of the site. I doubt it would come to that, though; even if it ran all day doing nothing but visiting every talk page, the servers wouldn't feel it. So you don't have to worry about the bot (any bot) taking Wikipedia down, but you do have to worry about the bot doing what it's supposed to, and the real problem you'll have is that it won't be able to process all pages in a day that way. I doubt sysadmins would help with that.

That's assuming it really works as naively as you say; there are many obvious ways to do this better (e.g. checking the API equivalent of Special:RecentChangesLinked, or checking the date of latest edit to the page, which can be done in batches of 500), and I would hope the bots already do something like that. Matma Rex talk 19:04, 7 March 2024 (UTC)

WP:DWAP doesn't magically make everything possible, no matter how inefficient it is. — Qwerfjkltalk 19:21, 7 March 2024 (UTC)

That will clutter our watch lists adding archiving to pages that may never need it. Why not just add it to pages over a certain size? Hawkeye7 (discuss) 19:06, 7 March 2024 (UTC)

I don't see talk pages on my watch list unless the talk page is edited or archived. The default setting for threads being archived is after there are a minimum of 4 threads. And only after the latest post in a thread reaches a certain age. And then only when there is a 5th thread started. Just adding archiving does not cause a lot of talk pages to show up instantly on watch lists. Because it takes awhile to reach those minimum number of threads. Many talk pages never get 4 threads. --Timeshifter (talk) 19:43, 7 March 2024 (UTC)

The default value for minthhreadsleft in Lowercase sigmabot III is actually 5 and that for ClueBot III's equivalent, minkeepthreads, is 0. Here's Lowercase sigmabot III's Python source code and that for ClueBot III in PHP. My Python is only beginner-level and my PHP is virtually nonexistent so I'm not 100% confident about the bots' exact mechanics, but I can't find any fancy API calls in either of the above links. We're getting way off-topic from the start of the thread though. Graham87 (talk) 12:01, 8 March 2024 (UTC)

Please see: User:Lowercase sigmabot III/Archive HowTo#Example 2: Incremental archives. It says minthreadsleft = 4 in the 2 copy and paste bits. I have copied that several times to talk pages. Farther down there is a table of parameters that says 5 for minthreadsleft. I don't think we are way off-topic. --Timeshifter (talk) 15:57, 8 March 2024 (UTC)

Timeshifter, yes, that's when the parameter is manually set. — Qwerfjkltalk 17:09, 8 March 2024 (UTC)

Speech synthesizer access to Wikipedia articles for the visually impaired

A user suggested that Wikipedia pages should include a link to a spoken version of the page. Speech synthesis is sufficiently inexpensve these days that I think the Wikimedia Foundation should investigate the possibility. JoshuaSzafranowicz (talk · contribs · count) @JoshuaSzafranowicz created a draft article, Draft:My suggestion is to add a voice box type of allowance to read off all articles to the user. That was the wrong way to make the suggestion, so I am adding it here and pinging the user. Eastmain (talk • contribs) 17:53, 5 March 2024 (UTC)

Most visually impaired people that need it will already have screen reader software available on their device. I don't see any advantage to doing it server-side. --Ahecht (TALK
PAGE) 18:18, 5 March 2024 (UTC)

The closest thing we have to that is Phonos, but it can not deal with anything close to an full article. See mw:Help:Extension:Phonos for instructions. See also c:Category:Spoken Wikipedia - English for audio files of old versions of English Wikipedia articles. I do agree tho that an voice box for an full article on Wikipedia itself is not necessary. Snævar (talk) 22:21, 5 March 2024 (UTC)

As a screen reader user, I completely agree with the replies to this thread. Graham87 (talk) 02:53, 6 March 2024 (UTC)

Other gallery template

Hi, is there an alternate gallery template which works like Random slideshow? Such template would be really useful for article I'm working on right now. Best regards Kazachstanski nygus (talk) 21:12, 5 March 2024 (UTC)

Random slideshow images are not allowed in articles, I think. There is probably a guideline somewhere. If you want to show multiple images in a small space, <gallery>...</gallery> tags are useful. See Help:Gallery tag for more information. – Jonesey95 (talk) 21:22, 5 March 2024 (UTC)

Wikidata error

Gangari dialect is showing "Lua error in Module:Endangered_Languages_Project at line 32: attempt to index field 'qualifiers' (a nil value)." I don't know how long the error has been there (I haven't check Category:Pages with script errors for a while). Module:Endangered Languages Project has recently been edited by Uanfala but I'm pretty sure there is no problem there. Stumbling around, it seems the problem is that for Gangadi (Q110251921), the first property in endangeredlanguages.com ID (P2192) has no qualifiers field. That first property is class of non-item property value (P10726). The module should not die if qualifiers is missing and something could be added to avoid that, but I'm wondering why the problem has arisen. Any ideas? Johnuniq (talk) 04:11, 6 March 2024 (UTC)

Temporarily fixed but code needs improvements — Martin (MSGJ · talk) 04:30, 6 March 2024 (UTC)

Thanks, I would never have thought of that change at Gangadi (Q110251921). I might look at patching the module later but it uglifies the code when trying to handle all of Wikidata's quirks. Johnuniq (talk) 05:27, 6 March 2024 (UTC)

It's something that's caught me out before! Lua throws a wobbly if you try to access a.b.c unless you first check that a.b exists, and before that to check that a exists. I'll take a look later — Martin (MSGJ · talk) 08:39, 6 March 2024 (UTC)

Should be fixed now. Just a bit surprised that (a) this issue has never occurred before and (b) RexxS made this mistake at all! — Martin (MSGJ · talk) 10:22, 6 March 2024 (UTC)

AI helper

Hello! Has there ever been talked about developing an AI helper for article editing/creating? I was tutoring in a wiki-activity today and one of the participants asked if there was such a thing. We were dealing with EnWiki and SqWiki (my homewiki) and even though we mentioned the possibility of help venues such as the Teahouse (or its equivalent in SqWiki) they explained that they were hoping for real-time artificial tutoring that could overseer their progress and fix any/most arising technical problems. I'm pretty sure in the age we live in that plan is not too farfetched so I was wondering if there has been any concrete work in this direction. - Klein Muçi (talk) 13:53, 6 March 2024 (UTC)

So I asked chatgpt what it thought about using AI to "create or edit articles" on Wikipedia. While it agreed that it had some benefits, it also mentioned the following concerns:

* The possibility of creating biased content.

* The likelihood that the results might re inaccurate or incoherent.

* Possible perception of AI undermining the "collaborative and volunteer-driven" aspects of Wikipedia.

* Risks associated with violation of copyright and responsibility for content.

Fabrickator (talk) 17:26, 7 March 2024 (UTC)

Fabrickator, hello and thank you for your interest! I would say my question wasn't exactly related to that. I meant having an AI helper that knows guidelines, manuals of styles, policies, etc. and helps the user follow them and face their technical difficulties that they may encounter along the way, for example, helping them use citation templates correctly or how and when to format a part of text as bold, how to sign up in discussions, etc. Its main purpose wouldn't be to help with the content per se but rather with using Wikipedia properly, policy/technically wise, what help venues like the Teahouse and wikimentors already do. — Klein Muçi (talk) 09:22, 8 March 2024 (UTC)

There are some learning helpers, they are not A.I. and do not need to be. An old one is The Wikipedia Adventure which teaches English Wikipedia guidelines and editing. Wikipedia:Growth Team features also teaches users through tasks, and it is upto your community to configure it in line with your policies. Edit check is the newest one, it is going to be a group of tests within the editors (VisualEditor and Wikieditor) that tell the user what to do. The first item in Edit Check will be an reference check, that tells an user to reference text if it is long enough. That length is configurable by your community. As for how to style citation templates, they should just let Citoid and RefToolbar autofill the citations for them.--Snævar (talk) 10:14, 8 March 2024 (UTC)

@Snævar: How do you know Edit check will support WikiEditor? Nardog (talk) 10:57, 8 March 2024 (UTC)

Oh, I am just confusing it with an different project. Information overload.--Snævar (talk) 14:44, 8 March 2024 (UTC)

Graphs: What now?

The recent conversation on T334940 has made what people have been afraid of pretty clear: Extension:Graph isn't coming back any time soon, and probably never. I think it's about time we come up with a "temporary" solution.

We have two problems to solve:

1. A replacement for the old graphs needs to be made and then dropped in.
2. Editors should have a way to make new graphs in a standardized manner without resorting to a photo editor.
   • Ideally, these graphs are easily updatable by new editors. This would be quite difficult though. I think a reupload of a file is going to be the minimum possible 'resistance'.

While we're at it, it'd be nice if our solution worked for the other wikis too.

For problem 1, my first thought is for a bot to download and build the graphs locally, and then upload them as SVGs and replace them in the affected pages. A tall order. I'm willing to look into it but I find it unlikely to be within my skills.

For problem 2, as TheDJ suggested, A toolforge tool could be the way to go. Snowmanonahoe (talk · contribs · typos) 15:55, 6 March 2024 (UTC)

Read mw:Extension talk:Graph/Plans. It covers what options there are instead of Extension:Graph and what those options can not do. There is also a list there, over the most used Extension:Graph templates on all Wikipedias. Snævar (talk) 00:04, 7 March 2024 (UTC)

For plain, horizontal bar graphs, I made for Category:Orphaned articles at the Progress section to "get it done". My initial thoughts were "something" better than "nothing". I understand this will not work for pie charts, & complex graphs. Regards, JoeNMLC (talk) 02:38, 7 March 2024 (UTC)

Pie charts will use Module:Piechart, an CSS+HTML based graph. Any interactive feature is gone. I did ask the devs if the graph system in Wikidata Query System could be used at phab:T357161, it would be for Wikidata-based graphs only. Snævar (talk) 10:06, 7 March 2024 (UTC)

Sad and embarrassing. jp×g🗯️ 09:15, 7 March 2024 (UTC)

What's especially embarrassing is the number of tickets such as T336595 and T222807 proposing alternatives that have been declined by the WMF as "we'll take a different approach", but no "different approach" has materialized. --Ahecht (TALK
PAGE) 15:09, 7 March 2024 (UTC)

One a related matter, has there been any movement on the possibility of using some form of SVG inline in articles? While full SVG could have security problems, a sanitized SVG (akin to the CSS in templatestyles) could be safe. This would be useful for creating graphs. —  Jts1882 | talk  15:16, 7 March 2024 (UTC)

Keep in mind that SVG's, although they are uploadable are shown as png's. Although mw:Manual:$wgSVGNativeRendering exists to send SVG's to the client, it has not been enabled on WMF wikis. So, the landscape is not looking good. I mean, if they are not going to trust SVG's to be sent to clients from WMF wikis, then why should inlike SVG's be worked on? There clearly still is distrust towards SVG's. Your feature is covered in phab:T334953, phab:T334372 and phab:T66460. So far these tasks have negitive comments. I would say inline SVG is not going to happen. Snævar (talk) 12:59, 9 March 2024 (UTC)

HotArticlesBot stopped running

HotArticlesBot, which builds lists of the most edited articles in each wikiproject, normally runs at 2:45am ET every night but last night did not run. I reported it to an operator very early this morning, but there hasn't been a response yet. This isn't a very critical bot, but wikiprojects use the results. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 19:00, 6 March 2024 (UTC)

For the main wikiproject I work on, I created a query at Quarry to replicate this bot's results, in case anyone needs it. Just substitute your project's category of included articles, and you're all set. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 20:40, 6 March 2024 (UTC)

StefenTower, have you tried {{database report}}? — Qwerfjkltalk 17:59, 7 March 2024 (UTC)

Yes, as a matter of fact, while working on Quarry queries yesterday, I discovered it, and immediately found a use for it, separate from this matter. As for HotArticlesBot, it got restarted last night. But at least now I know I have a potential way to replace it if it goes away. Thanks for the suggestion at any rate! Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:51, 7 March 2024 (UTC)

Source of Rapid Transit OSM Maps?

There's an outdated map at Kolkata Metro#Network map. I wanted to update it, and noticed that data is extracted from Wikidata, but there is no map in there. I tried reading the template documentation but couldn't understand much of it. Can anyone explain in layman's terms, where is the data coming from? And how to I update it? Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:22, 7 March 2024 (UTC)

The information is at OpenStreetMaps. It always confuses me. If you go to the Wikidata page for the system, Kolkata Metro (Q1048849), under has part(s) (P527) you have the six lines. If you go to each line they have a OpenStreetMap relation ID (P402) where the map shape information is or should be. E.g. Kolkata Metro Line 1 (Q6427301) links to the OSM relation 8034179. I think that is where the editing is needed, but I never got further than this. I only reply to point you in the right direction. Hopefully someone can provide a fuller answer soon. —  Jts1882 | talk  14:11, 7 March 2024 (UTC)

I've added the OpenStreetMap relation ID (P402) for the system at Wikidata. If you follow that to OSM relation Kolkata Metro (13994939) you can see it only has three members for lines 1-3. —  Jts1882 | talk  14:25, 7 March 2024 (UTC)

Thank you. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:27, 8 March 2024 (UTC)

How do i cite a default configuration file bundled with an Operating System?

(Copied from Teahouse per advice of User:ExclusiveEditor)

While editing the macOS text editing shortcuts section of Table of keyboard shortcuts, I got a table of all available shortcuts by dumping the system default configuration file with plutil(1) (you may notice that I mentioned it to support my edits in the edit summary). I think it's beneficial to cite it in the article, but don't know how. WP:CITE has no mention of configuration files, a quick google search turned up nothing either, so I came here to ask. Hym3242 (talk) 16:02, 7 March 2024 (UTC)

@Hym3242 the most important thing is to reference it, styling is secondary. A quick search for how to cite software came up with this. While using a citation template is handy, it is not required. So just <ref>Put in your source</ref> and you can let someone else worry about that. (They may chime in here with a better idea of course!). Note, no part of this response is a measure of if your source is actually a good type of source or not. — xaosflux ^Talk 16:50, 7 March 2024 (UTC)

Thank you! I know this may not be the best type of source, but in defense of my choice, macOS has many very useful but undocumented (in the official documentation/support pages/manpages) keyboard shortcuts that I hope to cover, and there are only two main ways to know about them: through Q/A sites / personal blogs, or by basically reverse engineering the software. The first one is obviously not generally acceptable on wikipedia. Hym3242 (talk) 18:17, 7 March 2024 (UTC)

LibreOffice now only shows "Fresh" version but not "Still" version

LibreOffice offers two concurrent versions: "Fresh" (hot off the press) and "Still" (stable, proven), however now it shows only "Stable" - this is not an adjective that The Document Foundation uses to describe either of its versions. See:

• Download LibreOffice

Currently, LibreOffice offers two concurrent releases:

• v24.2.1 If you're a technology enthusiast, early adopter or power user, this version is for you!
• v7.6.5 This version is slightly older and does not have the latest features, but it has been tested for longer. For business deployments, we strongly recommend support from certified partners which also offer long-term support versions of LibreOffice.

I posted a comment on the LibreOffice talk page on 2023-10-02, but there has been no response since then. I realize that this issue is connected to Wikidata, maybe Wikidata cannot handle two concurrent versions? Is there a work-around?
Enquire (talk) 05:45, 8 March 2024 (UTC)

List of State Of The Union Reports

Despite making over 1000 edits over many months, the wikipedia android app cripples me from creating my home page or any other new page, such as List of State Of The Union Reports, also responding on Talk: pages requires work-arounds. 3MRB1 (talk) 09:31, 8 March 2024 (UTC)

I suggest you try mobile web editor via your browser. — xaosflux ^Talk 15:20, 8 March 2024 (UTC)

Thoughts on DPL3?

I know Extension:DPL is used somewhat on Wikinews but is quite resource heavy. I wonder how would DPL3 work on Wikipedia? I think there would need to be some optimizations to make it work well, and we would likely have to limit the namespaces that DPL works in. Maybe there is a way to get a less resource heavy and more optimized DPL4 that has all of the features of DPL3 but without the performance problems of it.

Some uses I can see for DPL3 include getting the number of transclusions of a template, listing all of the pages proposed for deletion alongside their reasons, etc. Awesome Aasim 20:06, 8 March 2024 (UTC)

Bot that maintains GA nominations page is down

ChristieBot, which maintains WP:GAN, is down, and I don't know what the problem is; I would appreciate any help. It's particularly annoying as there is a backlog drive going on at the moment.

I was prompted by the WMF via phab:T357554 to upgrade to the new toolforge environnment. I made the suggested Python code changes, and ran into some problems when I tried to submit via the toolforge jobs command so I reverted to the code that was running earlier today (and I've checked that the reversion really did happen) and reenabled the cron job. Now when it runs it fails immediately with

ModuleNotFoundError: No module named 'importlib.metadata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "www/python/src/GANbot.py", line 20, in <module>
    import pywikibot
  File "/data/project/shared/pywikibot/stable/pywikibot/__init__.py", line 21, in <module>
    from pywikibot import config as _config
  File "/data/project/shared/pywikibot/stable/pywikibot/config.py", line 60, in <module>
    from pywikibot.backports import (
  File "/data/project/shared/pywikibot/stable/pywikibot/backports.py", line 206, in <module>
    import importlib_metadata
ModuleNotFoundError: No module named 'importlib_metadata'

Why is it now complaining about importlib.metadata? I tried exiting the tool and going back in via "become ganfilter" in case something from the toolforge job submit had changed the working environment but that didn't make any difference. Any help appreciated. Mike Christie (talk - contribs - library) 20:47, 8 March 2024 (UTC)

I have now managed to resolve at least one of the problems with the new toolforge version and it is giving me the same error about importlib.metadata on that version as well, so I seem to have the same problem both ways. Mike Christie (talk - contribs - library) 20:56, 8 March 2024 (UTC)

I've just realized that the bot stopped running just a few hours before I began working on it; I hadn't noticed it wasn't running. That means the problem is not related to the change to toolforge. Per a suggestion on phab I removed the PYTHONPATH environment variable but it is now complaining that it can't find pywikibot. I currently have PYWIKIBOT_DIR set to the .pywikibot directory in my tool's environment. If memory serves that's created at the time I built the tool. I tried removing the PYWIKIBOT_DIR but that didn't help, so I'd be grateful for any pointers to anything else I can try. Mike Christie (talk - contribs - library) 22:22, 8 March 2024 (UTC)

This looks to be partially because you're using the shared pywikibot installation which I wouldn't recommend as it can be changed without you knowing about it. It's also present at different locations depending on whether you use the Grid or Kubernetes. Feel free to add me as a maintainer – I can help sort it out. – SD0001 (talk) 10:03, 9 March 2024 (UTC)

SD0001, done -- thank you very much. Mike Christie (talk - contribs - library) 10:41, 9 March 2024 (UTC)

@Mike Christie I have created a fresh venv using the python3.11 image. Inside a webservice shell with the venv activated, I ran pip install pywikibot pymysql python-dateutil. Please create a requirements.txt with the list of dependencies and versions so that this would be smoother in the future. The user-config.py file was incompatible with the latest version of pywikibot (9.0.0) so I've moved that to user-config-old.py and created a basic new config file.

I validated a one-time run by running:

webservice python3.11 shell
source ~/www/python/venv/bin/activate
python ~/www/python/src/GANbot.py

The first two commands here should always be run before installing dependencies or running any python code, as the python version on the bastion is different from the one on k8s.

To automate it as a cron job, toolforge jobs run christiebot --command 'www/python/venv/bin/python www/python/src/GANbot.py' --schedule '0,20,40 * * * *' --image python3.11 should work, though I have not tested it. Once you confirm this works, set it up in a jobs.yml file so that in the future if any changes are required, you can just tweak the file and do toolforge jobs load jobs.yml. – SD0001 (talk) 12:16, 9 March 2024 (UTC)

SD0001 -- the job ran fine -- thank you. I tried running the same three commands that you ran, just to check that I understood what was going on, but source www/python/venv/activate fails with "No such file or directory". Is there something I'm missing? Re the requirements.txt, the packages the application imports are: urllib.parse re datetime pywikibot pymysql operator sys time dateutil.parser os configparser. I have put these in a requirements.txt in www/python/src though I would assume some of these are natively installed and don't need to be there; let me know which and I can remove them if necessary. Also, I've changed GANbot.py back to the toolforge code, which means configparser is probably not needed; I left it there in case I have more trouble getting the toolforge code to work. Mike Christie (talk - contribs - library) 14:22, 9 March 2024 (UTC)

And I meant to add that I have scheduled the job with the command you give and will check the results shortly. Mike Christie (talk - contribs - library) 14:24, 9 March 2024 (UTC)

@Mike Christie source www/python/venv/activate failure must be because you were not in the home directory. Sorry, I should have mentioned source ~/www/python/venv/activate so that it works from anywhere (once you have done become ganfilter, of course). It should be source ~/www/python/venv/bin/activate, edited above. – SD0001 (talk) 15:40, 9 March 2024 (UTC)

Mike Christie, just pywikibot and pymysql need to be in requirements.txt (per https://docs.python.org/3/library/) — Qwerfjkltalk 16:33, 9 March 2024 (UTC)

And python-dateutil. The versions should also be included (in pywikibot==9.0.0 format). The live versions can be via pip list. – SD0001 (talk) 16:39, 9 March 2024 (UTC)

Have updated requirements.txt, and the activate is now working so I am able to do one-off runs. Thanks again. Will set up the scheduled job next. Mike Christie (talk - contribs - library) 17:08, 9 March 2024 (UTC)

The scheduled job is working too. Thank you for all the help. I will create the yaml file and work on a few other cleanup issues such as possibly using the toolforge env vars rather than the config but this is now resolved. Mike Christie (talk - contribs - library) 17:30, 9 March 2024 (UTC)

Resolved

–Novem Linguae (talk) 18:11, 9 March 2024 (UTC)

Move with subpages succeeded – redirect not created for one subpage

I recently moved Draft:Article length bar to Template:Article length bar. This successfully moved 12 pages and created 11 redirects, with a missing redirect for Draft:Article length bar/styles.css. This is fine with me and I'm not asking for either a change in behavior, or an explanation; I'm posting this solely as an FYI to the community in case there are those who would want to know about this, as it does seem odd behavior. Adding Izno. Mathglot (talk) 02:51, 9 March 2024 (UTC) P.S. I have a Move succeeded screenshot showing one red link, if anyone wants it. Mathglot (talk) 03:04, 9 March 2024 (UTC)

This is normal. There is no such thing as a redirect in CSS. Izno (talk) 05:02, 9 March 2024 (UTC)

I just created a manual redirect there—Draft:Article length bar/styles.css, not that I need it—so if the Move process wanted to do it, presumably it could. If one *shouldn't* create a redirect because of the .css extension, that's another matter, but then it shouldn't let me create one, either. Mathglot (talk) 06:39, 9 March 2024 (UTC)

The redirect doesn't work if you try to import CSS from the page so it's misleading to have a redirect. A redirect is just a wiki page with certain code which is interpreted in a special way by MediaWiki. You can save anything in wiki pages, including invalid CSS like #REDIRECT [[...]]. PrimeHunter (talk) 10:18, 9 March 2024 (UTC)

I've deleted it. Indeed it is misleading to have a page like this. There isn't even a need for the original draft page redirects now that the page is main template spaced. Izno (talk) 16:51, 9 March 2024 (UTC)

For cases where there may be other uses of a given style sheet than an accompanying page/template, the original CSS file could be replaced with a CSS @import rule to include the file at its new location (unless $wgTemplateStylesAtRuleBlacklist has been configured on English Wikipedia to block it, assuming the page's content model remains sanitized CSS). However I agree in this case, there's no purpose for it. Draft pages should just have references to them updated. isaacl (talk) 18:59, 9 March 2024 (UTC)

Thanks, all; this has been enlightening. Mathglot (talk) 19:09, 9 March 2024 (UTC)

Severely shortened watchlist

I have thousands of pages on my watchlist. I have it set to show me the 250 latest items from the last seven days. I know there are that many items to show. But for some reason, without checking any of the "do not show" boxes except my own edits and wikidata, I am only seeing 15 items. If I hide bots, I get a normal-looking watchlist (without the bot edits). If instead I uncheck wikidata, I see more changes, but still nowhere near 250. Anyone know what is causing this and how I can get a full watchlist view that includes the bots? —David Eppstein (talk) 07:34, 9 March 2024 (UTC)

@David Eppstein perhaps you have another filer (such as a namesapce filter) on. When you use this link does it work? — xaosflux ^Talk 11:14, 9 March 2024 (UTC)

I wasn't filtering for namespace, but now it seems to be looking normal again. —David Eppstein (talk) 15:45, 9 March 2024 (UTC)

Wikipedia Data Issue: Who Do I Report This To?

Some Wikipedia articles are being attached to separate and distinct Wikipedia articles. This appears to be to increase viewership from search engines. For example, an article about X is attached to an article about Y. The article becomes X,Y and clearly draws search engine results to X. Who do I report this. It is very complicated.

Starlighsky (talk) 23:16, 9 March 2024 (UTC)

Please provide an example of exactly what you are seeing; what you expect to see; and why you think there is a technical problem. — xaosflux ^Talk 23:23, 9 March 2024 (UTC)

I just did. To me, at this point, I should contact technical support because publicly giving examples could cause me to be harassed. Starlighsky (talk) 23:29, 9 March 2024 (UTC)

Can you explain what "attached" means here? Is someone copying and pasting text from article X onto the end of article Y? Is it a comment about titles, that we have articles on Paris, on Texas and also on Paris, Texas? Does "attached" mean "wikilinked", and you feel that a certain article should not link to a certain other article? An example would really help us to understand what problem you may have found. Certes (talk) 23:45, 9 March 2024 (UTC)

All I know is that they take two thing unrelated. For example, it would be an article about sea turtles which is attached to an article about a specific car dealership. So it ends up being "Wikipedia: Specific car dealership.Sea Turtles".

It appears to be a way to increase search engine results for the car dealership. The mechanisms get more complicated, but that is the basic idea. I really need to contact technical support. Starlighsky (talk) 00:00, 10 March 2024 (UTC)

Is this a problem with some particular search engine (such as Google, Bing, DuckDuckGo, etc.) returning "Wikipedia: Specific car dealership.Sea Turtles" when you type in some search term? If so then the problem may not lie within Wikipedia. Six articles mention both car dealerships and sea turtles, but they seem to be legitimate entries without undue weight. For example West Edmonton Mall contains both a dealership and an aquarium. Unless you provide an actual example stating clearly where you are looking (e.g. reading Apple), what you see, what you expected to see and what is wrong, we are unlikely to be able to help you further. Certes (talk) 00:24, 10 March 2024 (UTC)

Here is an example:

John Murray Anderson's Almanac - Wikipedia (alquds.edu)

Whereas, it should be like this:

John Murray Anderson's Almanac - Wikipedia Starlighsky (talk) 00:37, 10 March 2024 (UTC)

I think this is some kind of sleazy SEO thing that the operators of those websites are doing. I don't know if we can really do anything about it (although I do note that they're just serving the Wikipedia logo with that page, which is trademarked, so maybe that has legs?) jp×g🗯️ 04:48, 10 March 2024 (UTC)

The article you linked is at https://wiki.alquds.edu – which is not Wikipedia, just a mirror of it, so there is nothing anyone here can do about it what happens there. Mirror sites which copy some articles from Wikipedia, or even all articles from Wikipedia, are permitted as long as they comply with the wmf:Terms of use. But no one here can dictate what they do on their own website, unless they are violating the Terms. Mathglot (talk) 05:06, 10 March 2024 (UTC)