Wikipedia:Village pump (technical)

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.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

Sticky header template for tables. Need iphone and Android testers

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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:

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

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

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

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

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)[reply]

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)[reply]

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:

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Request for comment from other iphone users

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia technical issues and templates

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

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)[reply]

@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)[reply]

Actually, I like it. RfCs should be a method of requesting comment from other users when a large scale is needed, not a vote on policy. The current system is far too bureaucratic. 🌺 Cremastra (talk) 19:58, 13 March 2024 (UTC)[reply]

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)[reply]

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

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)[reply]

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

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

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

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)[reply]

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

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)[reply]

@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)[reply]

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

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

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

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

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@Timeshifter Not sure what to test so I just expand every section on Sandbox243 on Safari, Chrome, Firefox, Edge, and Brave. Working in both orientation for all 5 browsers. — Paper9oll (🔔 • 📝) 06:11, 10 March 2024 (UTC)[reply]

@Paper9oll: Thanks. It looks like the Chrome and Edge landscape view problems in sandbox243 are gone too. --Timeshifter (talk) 15:24, 10 March 2024 (UTC)[reply]

@Timeshifter, Paper9oll, and LittlePuppers: Draft:Template:Sticky_header/doc is a draft of the new documentation that will replace the current one to explain the new styles. Feel free to edit it. Before replacing the live doc, the "/sandbox" text will need to be removed.

Most of this was discussed at Template talk:Sticky header#Template improvements, but I'll re-explain it so everyone is aware. After going live with the new styles, existing tables using the obsolete sticky class (used on row wikitext) will need to change to the sticky-header class (used on table wikitext). Also, existing sortable tables with more than one header row (multiple) will need the sticky-header class changed to the new sticky-header-multi class. The large majority of the tables using this template have one header row and use the sticky-header class, so they won't change.

If you think something might have been overlooked and more style changes are needed even if it is a better class name, then now is the time to mention it. Jroberson108 (talk) 16:52, 10 March 2024 (UTC)[reply]

It's up to you. If you feel comfortable with the Android situation without additional testers, then go live. If not, wait a few days for LittlePuppers. As for the new template doc it looks fine by me. I may make changes and additions later. I may not have a lot of time the next few days. --Timeshifter (talk) 02:42, 11 March 2024 (UTC)[reply]

I don't have an issue with going live with the Android issue and don't feel additional Android tests are needed. I'm just indicating I'm ready, but look it over one last time to make sure because tables are going to have to be manually changed after going live. If a class name changes after going live, then it's more work. If everyone is comfortable that this is more functional and easy for editors to use, then I may go live tomorrow or the day after. Jroberson108 (talk) 04:00, 11 March 2024 (UTC)[reply]

Class names for the new styles are fine by me. --Timeshifter (talk) 04:16, 11 March 2024 (UTC)[reply]

The new styles went live earlier today. Jroberson108 (talk) 06:34, 12 March 2024 (UTC)[reply]

Timeshifter, I just got back in town after being away for the past week and a bit so I don't have the time to look at this right now. Ping me again in a couple days if you still need me to look at something. LittlePuppers (talk) 01:13, 11 March 2024 (UTC)[reply]

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)[reply]

@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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Jts1882, I believe they will see an "Add topic" link. — Qwerfjkl talk 18:18, 5 March 2024 (UTC)[reply]

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)[reply]

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. — Qwerfjkl talk 18:02, 5 March 2024 (UTC)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]

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. House Blaster (talk · he/him) 04:33, 7 March 2024 (UTC)[reply]

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. House Blaster (talk · he/him) 04:37, 7 March 2024 (UTC)[reply]

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)[reply]

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. House Blaster (talk · he/him) 17:10, 7 March 2024 (UTC)[reply]

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)[reply]

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

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)[reply]

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. House Blaster (talk · he/him) 17:20, 7 March 2024 (UTC)[reply]

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. — Qwerfjkl talk 17:35, 7 March 2024 (UTC)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Timeshifter, yes, that's when the parameter is manually set. — Qwerfjkl talk 17:09, 8 March 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

Yes, thank you! Even though I'm more old school myself, I've seen that new editors love the VE so those are already appreciated. The only problem is that all these tools lack what they wanted in the first place: An AI wikimentor.

They were being helped by us at that moment and they expressed the need to have the same help and guidance all the time in real time, a mentor, 24/7. That's how AI was brought to attention. - Klein Muçi (talk) 14:01, 10 March 2024 (UTC)[reply]

ChatGPT can already answer most questions related to wikipedia editing. You probably don't need a dedicated AI as all wikipedia policy and guidelines pages are open and were presumably part of GPT's training data. – SD0001 (talk) 11:11, 10 March 2024 (UTC)[reply]

I thought that as well. If GPT can be an AI wikimentor, then the question could be rewritten to ask for better integration of GPT with Mediawiki?

(BTW, I use GPT extensively myself but I've yet to try and ask it about policies or MOS so I'm not sure how it does with those de facto.) - Klein Muçi (talk) 13:55, 10 March 2024 (UTC)[reply]

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:

A replacement for the old graphs needs to be made and then dropped in.
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

The only negative comment I see across all of these tasks is specific to client-side inline SVG. As discussed on phab:T334372, it very much makes sense to have inline SVG that is still server-rendered. I would say this is quite feasible. The task just hasn't caught the attention of the right people yet. – SD0001 (talk) 06:56, 10 March 2024 (UTC)[reply]

I find that post perplexing. You were the only person at that phab task to mention server-side rendering - specifically, you wrote the inline SVG can be server-rendered. It doesn't need to render on the client. If the SVG is inline, it must be rendered client-side. --Redrose64 🌹 (talk) 22:03, 10 March 2024 (UTC)[reply]

Please read comments 2–4 in the task. What makes you think if it's inline, it must be client-rendered? Math and Score extensions today allow inline use of Latex/LilyPond, that doesn't mean they render on the client. – SD0001 (talk) 22:29, 10 March 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

Resolved

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

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)[reply]

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

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)[reply]

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)[reply]

It's not exactly invalid CSS, but it's only partially valid. If we have a page Foo.css containing the single line

#REDIRECT [[Bar.css]]

what we have is (i) a valid ID selector matching any element having the attribute id="REDIRECT"; (ii) a valid descendant combinator (the space); and (iii) an attribute selector that would match any tag of the form <tagname Bar.css> or <tagname Bar.css="baz">, except that it is malformed by being enclosed in an extra pair of square brackets (how various browsers interpret those is not documented). What this "stylesheet" does not have is a declaration block (a pair of braces enclosing a declaration list); but whilst an empty declaration list is valid, I believe that the pair of braces is required. So consider it to be a do-nothing style sheet; but it certainly isn't a redirect in the MediaWiki sense of the word. --Redrose64 🌹 (talk) 16:12, 10 March 2024 (UTC)[reply]

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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I think alquds.edu has already been reported to the WMF for unauthorised use of WP trademarks. Nthep (talk) 07:13, 10 March 2024 (UTC)[reply]

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 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)[reply]

Yes, Al Quds is simply taking Wikipedia's content, which does not have the problem described here, and adding advertising. As Wikipedia is not adding the problematic text, and does not control or endorse Al Quds, the complainant's only recourse is to contact Al Quds and ask them to change their mirror. Certes (talk) 10:13, 10 March 2024 (UTC)[reply]

The user-generated content can be freely copied and redistributed in compliance with CC-BY-SA/GFDL, but using the Wikipedia name and logo is a trademark infringement. Nardog (talk) 10:26, 10 March 2024 (UTC)[reply]

Thanks to everyone for your help and insight. I just wanted to point it out to Wikipedia. I personally don't have problems with it, though. It seems the university appreciates U.S. cultural topics like Broadway shows and so on. I did want to report it in case it was something more serious. Starlighsky (talk) 13:34, 10 March 2024 (UTC)[reply]

Edit summaries forgotten

Until late last night when I started typing in an edit summary field it came up with precious summaries that started with the same letters. This was very useful for some of the work I do, eg fixing Category:Harv and Sfn no-target errors. At some point late last night it stopped doing this, and likewise this morning. I haven't changed any settings on WP or on my computer. How do I make it start remembering edit summaries again? Thanks, DuncanHill (talk) 11:27, 10 March 2024 (UTC)[reply]

I'm pretty sure that behaviour originates in your browser, not in any Wiki software. -- Michael Bednarek (talk) 14:35, 10 March 2024 (UTC)[reply]

It does not remember your past edit summaries because something cleared or stopped using your autofill cache in your browser. It is only possible to help if you say what browser you are using. Maybe the website of the browser knows more than people here. You can ask here for a list of your edit summaries, if you find that useful. Snævar (talk) 14:19, 11 March 2024 (UTC)[reply]

Browser is Edge version 122.0.2365.80 (Official build) (64-bit). As I said, I haven't changed any settings on it. DuncanHill (talk) 12:29, 13 March 2024 (UTC)[reply]

This is not a feature coming from us. Browser-configuration of such a feature is using in the "autofill" or "forms" configuration of your browser. Certain privacy extensions may suppress this as well. — xaosflux ^Talk 13:57, 13 March 2024 (UTC)[reply]

As I said, I haven't changed anything. If it helps, no other forms or autofill behaviour has changed, even on Wikipedia. Just edit summaries. DuncanHill (talk) 14:06, 13 March 2024 (UTC)[reply]

I didn't know that Edge could remember edit summaries. Internet Exploder certainly couldn't. --Redrose64 🌹 (talk) 14:17, 13 March 2024 (UTC)[reply]

@DuncanHill is this when using discussion tools, the standard editor, or both? My browser never remembers these for DT. — xaosflux ^Talk 14:23, 13 March 2024 (UTC)[reply]

I don't know what discussion tools are, so presumably the standard editor. The change in behaviour happened in the course of the evening. DuncanHill (talk) 14:31, 13 March 2024 (UTC)[reply]

Wikipedia:Discussion Tools. The primary setting is at Preferences → Beta features and there are several more at Preferences → Editing. --Redrose64 🌹 (talk) 14:41, 13 March 2024 (UTC)[reply]

I don't use any Beta features. On the Editing prefs page under "Discussion pages" "Enable quick replying", "Enable editing tools in source mode", and "Enable topic subscription" have all been ticked (but not by me, I am sure). The problem is on all pages, not just Talk. DuncanHill (talk) 15:01, 13 March 2024 (UTC)[reply]

I've just unticked those and it doesn't seem to make any difference. DuncanHill (talk) 15:05, 13 March 2024 (UTC)[reply]

Find and click on three dots in the top right of your browser window, click "Settings". On the page that appears select "Privacy, search and services" on the left side. Go to the "Clear browsing data" heading. Open "Choose what to clear every time you close the browser". Find if the option for autofill is on or off (should be off). Snævar (talk) 10:56, 14 March 2024 (UTC)[reply]

It is off. It's always been off. I think I mentioned that "I haven't changed any settings on WP or on my computer". The only change in behaviour has been to one field on Wikipedia. DuncanHill (talk) 11:01, 14 March 2024 (UTC)[reply]

Badly legible lengthy talkpage Talk:Limburgish

Hello,

maybe that is an unusual comment for this talk page. Talk:Limburgish is a talk page which is not only difficult to read and not formatted properly, all of which partly is caused by me. What can I do to render the talk page in line withg the rules?

Kind regards Sarcelles (talk) 21:06, 10 March 2024 (UTC)[reply]

Answered on that talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:40, 10 March 2024 (UTC)[reply]

It was halved by an archive bot. However, the disputes are unresolved. Sarcelles (talk) 16:55, 11 March 2024 (UTC)[reply]

By now, further parts of the article have been removed by bot. Half a year ago, an author using changing IP adresses caused hustle across Wikimedia by forcing decisions. This user seemed to refuse to differentiate between German Wikipedia and other Wikimedia projects. Sarcelles (talk) 21:02, 14 March 2024 (UTC)[reply]

General edit notice

When I edit any article I see a notice saying:

Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable through citations to reliable sources.

Where is that text kept, and where can I suggest changes to it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:36, 10 March 2024 (UTC)[reply]

I think it's MediaWiki:Editpage-head-copy-warn. Its talk page might be a good spot to discuss changes. –Novem Linguae (talk) 21:42, 10 March 2024 (UTC)[reply]

Yes, there's already discussion at MediaWiki talk:Editpage-head-copy-warn#New design. Certes (talk) 21:47, 10 March 2024 (UTC)[reply]

Hello not sure where to put this

Where do I go to ask WMF to support WikiLovesiNaturalist or similar in maintenance, uptime, expansion? The iNaturalist to Commons pipeline is precious and invaluable and having it kinda automated with license checks and all the metadata connected is Very Very Good. Not sure how to pursue this but it's spring and my social media is rich with "check out this rare wildflower I saw" posts and I want to create stubs for them all but WikiLoveiNat is having uptime challenges which slows down the stub-illustration process. Thanks in advance for guidance. jengod (talk) 00:13, 11 March 2024 (UTC)[reply]

Looks like the maintainer is @Jon (WMF). Pinging them so you two can connect. –Novem Linguae (talk) 02:25, 11 March 2024 (UTC)[reply]

TYSM @Novem Linguae and hi @Jon (WMF) 👋 I love your tool and wrote about it in Signpost which I hope you saw: Wikipedia:Wikipedia Signpost/2024-02-13/Gallery

jengod (talk) 02:29, 11 March 2024 (UTC)[reply]

Changelog?

Resolved

– Information provided. — xaosflux ^Talk 09:58, 11 March 2024 (UTC)[reply]

I noticed undos now automatically make the revision id into a clickable link like some other Wikis did (I no longer need to do it manually or use my script, awesome :D) - where can I read about such changes, is there a changelog? – 2804:F14:80C6:A301:70C8:DCC8:4027:D6BB (talk) 00:54, 11 March 2024 (UTC)[reply]

MediaWiki talk:Undo-summary#Protected edit request on 7 March 2024. Looks like the change in MediaWiki took place last May, but here the message was overridden so it wasn't affected until recently. Nardog (talk) 03:27, 11 March 2024 (UTC)[reply]

Ah, I thought it was a per-wiki thing. Still, good change. Thank you for requesting that Eyesnore. – 2804:F14:80C6:A301:70C8:DCC8:4027:D6BB (talk) 03:56, 11 March 2024 (UTC)[reply]

Shortcut box too wide when placed in tmbox

Example.

Please note the very wide shortcut boxes at the top of the example page (search for WP:NEWCSD and WT:CSD). Normally shotcut boxes are the same width as their text. In this case they're about triple or quadruple the width of their text. Any idea what is causing this? I think I saw this in one other place too but I forgot to write down the page.

An incorrect edit in pursuit of supporting dark mode. Izno (talk) 03:29, 11 March 2024 (UTC)[reply]

Unable to find lint errors

I'm trying to fix two lint errors on Everybody's Got to Learn Sometime (unclosed div tag and unclosed table tag, as reported by LintHint), one or both of which is causing the article to display incorrectly on mobile, with all sections under "Other versions" getting collapsed into that section (very similar to this issue I previously asked for help with). The issue is, I can't find any div or table tags in the source, let alone any unclosed ones. What's the best way to find where exactly the issue is? Suntooooth, it/he (talk/contribs) 13:57, 11 March 2024 (UTC)[reply]

@Suntooooth: That section has a {{col-begin}} without a {{col-end}}. I don't know any clever way to spot this kind of error; I compared the markup for that section with the markup of the preceding sections. -- John of Reading (talk) 14:19, 11 March 2024 (UTC)[reply]

@Suntooooth looks like it is within the col-begin or col-2 templates. — xaosflux ^Talk 14:23, 11 March 2024 (UTC)[reply]

@Xaosflux and John of Reading: thanks for the help! I removed all the col templates - nothing seemed to break and it fixed the issue, so I'm not sure why they were there in the first place. Good to know that col templates can cause lint errors like that! Suntooooth, it/he (talk/contribs) 14:34, 11 March 2024 (UTC)[reply]

Tech News: 2024-11

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

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 March. It will be on non-Wikipedia wikis and some Wikipedias from 13 March. It will be on all wikis from 14 March (calendar). [1][2]
After consulting with various communities, the line height of the text on the Minerva skin will be increased to its previous value of 1.65. Different options for typography can also be set using the options in the menu, as needed. [3]
The active link color in Minerva will be changed to provide more consistency with our other platforms and best practices. [4]
Structured data on Commons will no longer ask whether you want to leave the page without saving. This will prevent the “information you’ve entered may not be saved” popups from appearing when no information have been entered. It will also make file pages on Commons load faster in certain cases. However, the popups will be hidden even if information has indeed been entered. If you accidentally close the page before saving the structured data you entered, that data will be lost. [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][7]

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

MediaWiki message delivery 23:02, 11 March 2024 (UTC)[reply]

Problem with map

Does anyone else see a problem with the infobox on WonderWorks (museum)?— Vchimpanzee • talk • contributions • 16:57, 12 March 2024 (UTC)[reply]

The article has no co-ordinates, as it's a multi site establishment. {{infobox museum}} appears to automatically add a map but here has no co-ordinates to work on. I've added |mapframe=no to the infobox to switch the map off. Nthep (talk) 17:13, 12 March 2024 (UTC)[reply]

Nthep, I assumed the issue was to do with Wikidata, WonderWorks (Q8031719) has coordinates. — Qwerfjkl talk 17:27, 12 March 2024 (UTC)[reply]

The infobox makes mapframe code which produces a map made by mw:Extension:Kartographer. Kartographer can pull data from OpenStreetMap. I don't know the details but I guess OpenStreetMap has data which reflects there are multiple WonderWorks locations, unlike the Wikidata item which only has coordinates for the Orlando, Florida location. The map ends up in water west of the Florida peninsula. PrimeHunter (talk) 20:37, 12 March 2024 (UTC)[reply]

It's called the Gulf of Mexico. --Redrose64 🌹 (talk) 21:00, 12 March 2024 (UTC)[reply]

A more robust editnotice loader

I am working on a module editnotice load that can more robustly load editnotices. Some of the features I am adding include:

Support for category notices without the use of JavaScript (but it is a bit intensive of post-expand include limit for big articles)
Moving pages does not necessitate moving editnotices (using PageID)
Possible removal entirely of the traditional /Editnotice for user page editnotices, but backwards compatibility for the latter

I am doing tests on test.wikipedia.org. Unfortunately there isn't a method to extract out the categories from a page so I had to use a costly Lua hack. testwiki:Special:EditPage/Taylor_Swift. I want to see if there is room for improvement. Awesome Aasim 18:54, 12 March 2024 (UTC)[reply]

Problem with link to article...

When I use the link to the Wikipedia article, which is Ager, Yellen, and Bornstein, Inc. - Wikipedia ,

it goes to Ager, Yellen, and Bornstein, Inc - Wikipedia with the following odd repetitious message:

Ager, Yellen, and Bornstein, Inc.

	Did you mean: Ager, Yellen, and Bornstein, Inc.?

Starlighsky (talk) 00:18, 13 March 2024 (UTC)[reply]

Hmm... I am not having this problem. Ager, Yellen, and Bornstein, Inc. Ager, Yellen, and Bornstein, Inc. Did you try adding ?safemode=1 to the URL and seeing if you have the same issue? If so it could be an issue with a user script. If not it might be a browser extension or your own browser. Awesome Aasim 00:38, 13 March 2024 (UTC)[reply]

@Starlighsky: Where do you see the broken link? The title Ager, Yellen, and Bornstein, Inc. ends in a period so the url also does: https://en.wikipedia.org/wiki/Ager,_Yellen,_and_Bornstein,_Inc. Many programs will omit the period when they see the url as plain text and try to convert it to a clickable link. That also applies to MediaWiki: https://en.wikipedia.org/wiki/Ager,_Yellen,_and_Bornstein,_Inc. The "Did you mean" message was made to help readers who clicked such a link somewhere. PrimeHunter (talk) 01:05, 13 March 2024 (UTC)[reply]

Thanks! Starlighsky (talk) 01:33, 13 March 2024 (UTC)[reply]

Probably could just drop the "inc" on an aside. Izno (talk) 16:55, 13 March 2024 (UTC)[reply]

I dropped the period, and it is working now. Starlighsky (talk) 22:55, 13 March 2024 (UTC)[reply]

Wikipedia:Naming conventions (companies)#Default to the most common name says to not include Inc. PrimeHunter (talk) 00:29, 14 March 2024 (UTC)[reply]

I just did exactly that. Problem solved. Starlighsky (talk) 01:58, 14 March 2024 (UTC)[reply]

Country demonyms

Resolved

Once again, I've come across a situation where the changeover of a category from "manually coded navseason and categories" to "preformatted template that autogenerates everything" broke categorization because of a difference between the demonym our category is actually located at and the demonym autogenerated by the template.

The category was Category:20th-century Kyrgyzstani educators, and the act of switching it over from {{Navseasoncats}} to {{Educators by nationality and century category header}} caused the categories for Category:20th-century Kyrgyzstani people and Category:Kyrgyzstani educators to get replaced with nonexistent redlinks at "Kyrgyz" instead of "Kyrgyzstani". I brought a similar case to VPT last year when the same thing happened to a Tajik/Tajikistani category — and as I said that time, I don't have the depth of knowledge necessary to know whether the categories should be at Kyrgyz or Kyrgystani, but either way it is necessary that whichever form they're at the template uses the form they're at rather than generating redlinks for the opposite.

For the moment I've had to work around the problem by wrapping the template in {{suppress categories}} and manually readding the category declarations that were on it before the switchover, but that virtually defeats the entire purpose of the switchover — so could somebody look into how to resolve this? Bearcat (talk) 15:57, 13 March 2024 (UTC)[reply]

I would probably revert the edit, drop a note on the editor's talk page, and maybe post a note at Template talk:Educators by nationality and century category header. This doesn't seem like a VPT problem until you have contacted Smasongarrison via the usual mechanisms. – Jonesey95 (talk) 16:30, 13 March 2024 (UTC)[reply]

It's not an error on Smasongarrison's part. It was a perfectly reasonable edit where they did the right thing and it had unintended side effects not caused by them, not a mistake they made that discussing with them would solve. Bearcat (talk) 20:22, 13 March 2024 (UTC)[reply]

Thanks for your diligent gnoming, but sometimes getting the problem fixed is better than working around it. That editor created the template in question and added it to the category page, so their talk page or the template's talk page seem like good places to start. Coming here to "Once again..." at VPT every time someone inadvertently links to a red category might not be the best way to resolve problems. Shit happens. I have fixed this problem by tracking down the problem to Module:Find demonym. I have edited the module; see my edit summary for details. If other pages or categories were depending on "Kyrgyz" to be output from that module, they may malfunction, but the module is currently consistent with the vast majority of relevant category names and with Module:CountryAdjectiveDemonym/Adjectives. – Jonesey95 (talk) 21:19, 13 March 2024 (UTC)[reply]

I'm glad to hear that this was resolved. And, now I know that find demonym exists, so that's exciting! I can definitely build in a check to see if the demonym breaks. Mason (talk) 21:37, 13 March 2024 (UTC)[reply]

Certainly is an error on Smasongarrison's part. Although the change seemed reasonable, it needed much fuller testing, and the related modules to be fixed. This is a change management problem and templates and modules need a lot more care in implementing changes. Graeme Bartlett (talk) 22:21, 13 March 2024 (UTC)[reply]

If you don't know what to do, leave it for others to fix it. Using hacks such as suppress categories just hides the problem and does not fix anything. Gonnym (talk) 21:41, 13 March 2024 (UTC)[reply]

It's neither my job nor my responsibility to do nothing. Every time Special:WantedCategories updates with new redlinks, every single category on it has to be created or wiped out immediately, with no "do nothing" exceptions for any reason ever, because the list has to be cleared to absolute zero before the next time it updates. The report has a hard numeric limit beyond which it cannot detect additional redlinks at all, so there cannot be any do-nothings that don't get fixed and carry over from one report to another, because every one of those that fails to get resolved pushes the list closer to that cap — so the list getting cleared to zero each time it runs is mandatory and non-negotiable, and I will take no lectures or clapback from anybody about it. Bearcat (talk) 22:41, 13 March 2024 (UTC)[reply]

"Immediately"? It looks like the page was last updated more than 17 hours ago, so presumably we have at least that long to resolve problems. Also, it looks like the numeric limit is 5,000 links, and there are 138 links on the most recent report, so claiming that every single entry, without exception, needs to be removed before the next update also seems hyperbolic. Exaggeration and hyperbole might do well to be replaced by a bit of AGF, discussion, and patience. Maybe there is something I do not understand, but that's how it looks from here. – Jonesey95 (talk) 23:02, 13 March 2024 (UTC)[reply]

If I leave behind one now, then I'm automatically surrendering any argument that there's any need to clear even one of the other 137 anymore — if I give one redlinked category any special dispensation to stick around unresolved because reasons, then I have to let them all stick around unresolved because why should they be treated any differently than the one I'm not dealing with? Plus, 138 is lower than usual for that report — 200 is more normal, and even then it's only that low because most established editors know that redlinked categories are verboten, and would be a lot higher than that otherwise. So if I don't deal with 138 categories now, then it's 338 by Saturday, and 538 by next Tuesday. And then word gets out that redlinked categories are fine and dandy now, so their use explodes so that there are 2,000 redlinked categories to deal with by next Friday, 4,000 by the Monday after that, and the 5,000 limit has been hit by Easter Weekend.
That's why the fact that there is a limit always has to be taken into account regardless of how far away from it any one particular generation of the report may seem to be — because if redlinked categories aren't dealt with right away, the problem doesn't just slowly grow at a rate of only 130 categories every three days: it goes supernova the moment word gets out that redlinked categories aren't considered a problem anymore, and the limit thus gets hit within two to three weeks at most. Bearcat (talk) 00:04, 14 March 2024 (UTC)[reply]

Aside from the fact that there are two permanent residents on that category report, negating your entire thesis, that kind of slippery-slope, catastrophic, Manichaean thinking is simply not necessary. We have WP:CATREDLINK, a guideline that explains that an article should never be left with a non-existent (redlinked) category on it, so nobody should reasonably conclude that the existence of one or two red-linked categories on a report for two or three days will inevitably lead to human sacrifice, dogs and cats living together, mass hysteria. For word to get out that red-linked categories were suddenly acceptable, the guideline would have to change, which is unlikely. In general, it's better to resolve problems properly than to work around them and possibly sweep them under the rug. It can sometimes take a few hours or days to resolve problems properly, as it did in this case. That's OK. – Jonesey95 (talk) 01:56, 14 March 2024 (UTC)[reply]

Gadgets at Wicipedia Cymraeg

Wicipedia Cymraeg (Welsh Wikipedia) does not have a gadgets tab at cy:Special:Preferences. Therefore, to use gadgets, it is necessary to load them into your personal common.js and/or common.css files. Gadgets may be imported from another Wikipedia, and this is easy for gadgets that are pure CSS - for example, for "Move section [edit] links to the right side of the screen", our MediaWiki:Gadgets-definition file has the line

righteditlinks [ResourceLoader] |righteditlinks.css

which indicates that this gadget has a CSS file but no JS file, thus it may be anabled at Wicipedia Cymraeg by adding the line

@import "//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-righteditlinks.css&action=raw&ctype=text/css";

to cy:Special:MyPage/common.css. Done, tested, working, no problem here. However, if the gadget has a Javascript component, for example, "Add an [edit] link for the lead section of a page", our Gadgets-definition file has the line

edittop [ResourceLoader |dependencies=user.options, mediawiki.util |type=general] |edittop.js |edittop.css

which indicates that this gadget has both a JS file and a CSS file, plus some dependencies. What is the best way of loading the JS file into cy:Defnyddiwr:Redrose64/common.js together with its dependencies? --Redrose64 🌹 (talk) 22:26, 13 March 2024 (UTC)[reply]

cy:Special:Version#mw-version-ext-other-Gadgets shows mw:Extension:Gadgets is installed. The gadgets tab should appear automatically if an interface administrator creates cy:MediaWiki:Gadgets-definition with at least one valid gadget. There are two interface administators cy:Arbennig:ListUsers/interface-admin and one of them is active. PrimeHunter (talk) 23:53, 13 March 2024 (UTC)[reply]

The active one is Llywelyn2000 (talk · contribs), and if they wanted gadgets they would presumably have set some up by now (see Wikipedia:Village pump (technical)/Archive 180#Loading gadgets on another Wikipedia from four years ago). Based on that, I have done this, but I don't know if that's the correct way or not. It seems to work, but I don't know if it's causing undesirable side-effects, or is using outdated code that may fail at any time. It would have helped a lot if you had said "using this basic framework, you pass in these values here and here. --Redrose64 🌹 (talk) 01:03, 14 March 2024 (UTC)[reply]

Gadget that helps edit templates via TemplateData

TemplateWizard is great when you want to add a new template, but it doesn't work when you want to edit an existing template. Is there any existing tool or gadget that can help here? VisualEditor is great but it doesn't work in talk/wikipedia namespaces. ԱշոտՏՆՂ (talk) 03:57, 14 March 2024 (UTC)[reply]

It does, you just have to do the work to turn it on yourself. See an example. Izno (talk) 15:31, 14 March 2024 (UTC)[reply]

Templates stop working after a certain number (of templates) is transformed (timeout/load protection?)

The page in question (Missing Wikipedians) is a large list of Wikipedia users, Template:User2 is used extensively throughout the page.

Somewhere around the middle of this section, templates turn into link to the template used, instead of whatever should've appeared in place of said template.

Examples:

Template:User2 shows up instead of Thanatosimii (talk · contribs · count)
Template:Mop Template:Former admin shows up instead of
‹ The template below (Mop) is being merged. See templates for discussion for the discussion that led to this result. ›
{{{CRITERION}}}

TFOWR (talk · contribs · former admin: blocks · protections · deletions · rights · meta · local rights)

Purging doesn't help. The last known good revision dates back to 22:40, 31 October 2023

--Moon darker (talk) 04:52, 14 March 2024 (UTC)[reply]

See Help:Template#Template_limits. ԱշոտՏՆՂ (talk) 05:28, 14 March 2024 (UTC)[reply]

Thanks, that's exactly what it felt like, but I somehow missed that limits page. Moon darker (talk) 06:20, 14 March 2024 (UTC)[reply]

Bug in the "What links here" function?

After a multi RM, I went back to fix double redirects. When doing so, I discovered a possible bug in the "What links here" function.

What happens is that there first seems to be one [double] redirect only. I fix it, and then return to the "What links here" special page. I refresh: the changed redirect now shows in expected place – but then one or two new redirects appear in the list!

Why didn't they show before? I think the issue is somehow related to the sorting order in the "What links here" page: after the "Wikipedia" article name space, which is shown last (possibly except for "Wikipedia talk"), the function does not expect more pages – so it doesn't even try. The list in the function wasn't always sorted on article name space, was it?

I have saved the last article in the multi RM for a technician to "debug" if they wish: List of people associated with Wadham College, Oxford. There is a single double redirect (and articles linking to it), but I expect more to appear after it's fixed.

P.S. This appears – at least to me – unrelated to the 500 limit on showing links to redirects. Few articles link to the articles in the RM, even if you include links to redirects. HandsomeFella (talk) 07:00, 14 March 2024 (UTC)[reply]

Is it possible that the unlisted pages were triple redirects, and that your fixing something else turned them into (less bad) double redirects? WhatLinksHere lists double redirects, indented, but I don't think it recurses into them to list triple redirects. For example, if R3 redirects to R2 redirects to R1 redirects to article A, R2 is listed indented within R1 but R3 is not listed. If you then fix R2 to redirect directly to A, R3 will appear indented within the top level redirect R2. Certes (talk) 09:44, 14 March 2024 (UTC)[reply]

Some pages not appearing in the Watchlist

I've observed that some pages (for example Muhammad Aurangzeb) are added to my watchlist at Special:EditWatchlist but are not appearing in the watchlist itself at Special:Watchlist. Does anyone know why this might be happening? Saqib (talk) 10:26, 14 March 2024 (UTC)[reply]

@Saqib: Your watchlist options may exclude the page. For example, I exclude my own edits. If you do the same then your edit to Muhammad Aurangzeb won't show up and the page might not be on your watchlist unless the time period covers the previous edit too. Certes (talk) 13:03, 14 March 2024 (UTC)[reply]

@Certes: If you're suggesting that pages last edited by me won't show up on my watchlist, then why do the rest of the pages, where I'm also the last editor, appear on my watchlist? --Saqib (talk) 14:14, 14 March 2024 (UTC)[reply]

I can't see what options you have set, so I'm making blind guesses and may well be wrong. In the "Watchlist Options" panel, on the "Hide:" row, I have a tick to the left of "my edits". That means a page doesn't appear if its only recent edits are mine. I still see pages other people edited, even if I also edited them. This may or may not be causing what you see, or there may be another of the Hide: options filtering out the pages. If not then I apologise for wasting your time. Certes (talk) 15:01, 14 March 2024 (UTC)[reply]

I'm unable to find any watchlist settings which show the latest edit [8] to Muhammad Aurangzeb. PrimeHunter (talk) 15:39, 14 March 2024 (UTC)[reply]

I have the same issue. Firefangledfeathers (talk / contribs) 15:44, 14 March 2024 (UTC)[reply]

If you use this link with all filters and scripts off does it work? — xaosflux ^Talk 18:18, 14 March 2024 (UTC)[reply]

The page (Muhammad Aurangzeb) is appearing now in the watchlist, on its own. Strange. --Saqib (talk) 20:20, 14 March 2024 (UTC)[reply]

Auto-Purge

Is their any script/ template on Wiki^p so if put in a page, every time any user refreshes/ visits the page, it auto purges. For example I could put it in my random number generator, so every time anyone visit/ refresh the page, its gets purged. ExclusiveEditor _{Notify Me!} 11:01, 14 March 2024 (UTC)[reply]

No. You can't force other users to perform actions. — xaosflux ^Talk 14:16, 14 March 2024 (UTC)[reply]

New alias for template namespace

On Wikipedia, it'd be great if an alias for the template: namespace was created, such as how wp: is an alias to theWikipedia: namespace, which would allow for faster searching of templates in the search bar.

For that, I would propose eithertp:, or t:. Please state which you prefer below, so I can add a task in phabricator! Cheers, Cocobb8 (💬 talk • ✏️ contribs) 12:19, 14 March 2024 (UTC)[reply]

You might like to read Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces — Martin (MSGJ · talk) 12:38, 14 March 2024 (UTC)[reply]

Great, thanks @MSGJ! Tp: doesn't seem to be listed there, however. Could that work as a new proposition? Cocobb8 (💬 talk • ✏️ contribs) 13:43, 14 March 2024 (UTC)[reply]

While these sort of things COULD happen technically (assuming the value is not in collision) - it very much likely won't be. For one: why? Templates are already directly short-cutted to via {{}}. — xaosflux ^Talk 14:15, 14 March 2024 (UTC)[reply]

The advantage of a namespace shortcut is that I don't have to type Template:… in the searchbox when I want to visit a template to read its documentation, which I do a lot. -- Michael Bednarek (talk) 14:32, 14 March 2024 (UTC)[reply]

@Xaosflux, @Michael Bednarek: Yeah, that's what I was getting at: when editing you for sure can use {{}}, but for looking up the template docs in the search bar typing in template: eats some time, which is where tp: could be handy. Cocobb8 (💬 talk • ✏️ contribs) 14:56, 14 March 2024 (UTC)[reply]

@Cocobb8 ~~If you're using the older Vector skin~~ you can use User:Ahecht/Scripts/TemplateSearch to replace {{ in the search box with Template: automatically. ~~I've tried getting it to work on the newer Vector 2022 skin, but it's not reliable.~~ --Ahecht (TALK
PAGE) 15:24, 14 March 2024 (UTC)[reply]

Ah great thanks, but it'd be great to have something that works on all skins just like wp: Cocobb8 (💬 talk • ✏️ contribs) 15:26, 14 March 2024 (UTC)[reply]

I did some debugging on the script, and it's now working better in Vector 2022 and Minerva. It should also work on most older skins, including Monobook, Modern, and CologneBlue. --Ahecht (TALK
PAGE) 17:56, 14 March 2024 (UTC)[reply]

Installed, works nicely on Vector 2022! There is a very minor issue that when shift is still held when typing in {{, the field will stay 1 second on Template: and then go back to {{. It will however go back to Template: once the shift key is released. Cocobb8 (💬 talk • ✏️ contribs) 18:01, 14 March 2024 (UTC)[reply]

FWIW, this was recently proposed and withdrawn from the wishlist (meta:Community Wishlist Survey 2023/Archive/Create an alias for the Template namespace) — xaosflux ^Talk 15:24, 14 March 2024 (UTC)[reply]

That was for t: though, not tp: Cocobb8 (💬 talk • ✏️ contribs) 15:26, 14 March 2024 (UTC)[reply]

Also, this isn't really a technical challenge - it is possible and some projects have done it (e.g. ganwiki who even changed alphabets and made T:-->模板: in phab:T355854). You would need to make a proposal, have it well advertised and well attended, and gain community consensus for the change. — xaosflux ^Talk 15:26, 14 March 2024 (UTC)[reply]

Would phabricator be all right or is there another space to propose it? Cocobb8 (💬 talk • ✏️ contribs) 15:28, 14 March 2024 (UTC)[reply]

No, it would need to be here on-project. Once approved by the community, then the technical task would opened at phab. See Wikipedia:Requests for comment for how to write a RFC. At a minimum it should be listed at WP:VPR. — xaosflux ^Talk 15:30, 14 March 2024 (UTC)[reply]

Ok, will do later this week Cocobb8 (💬 talk • ✏️ contribs) 15:31, 14 March 2024 (UTC)[reply]

European Figure Skating Championships#Medalists

We have encountered a strange technical bug while inserting new templates into the tables for this article. The issue is visible beginning with 1978 on the Pairs table. I do not see where something was entered wrong at that point that would cause all of the subsequent templates to not display properly. Any advice would be appreciated. Pinging Hyperion82. Bgsu98 (Talk) 20:43, 14 March 2024 (UTC)[reply]

See WP:PEIS. The rendered page is too big. If you ask nicely, someone here might be willing to modify {{FS medalist}} to use the flagicon module, which should help. – Jonesey95 (talk) 21:12, 14 March 2024 (UTC)[reply]

I sure would appreciate any assistance in this matter. I'm sure the user who created that template would not mind at all. Bgsu98 (Talk) 21:33, 14 March 2024 (UTC)[reply]

Substing the whole medalist section, apart from cite web and the "Cumulative medal table" section (they do not like being subst), brings PEIS down to 1,982,442/2,097,152 bytes. Snævar (talk) 21:48, 14 March 2024 (UTC)[reply]