Wikipedia:Village pump (technical)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
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
I am worried that there may be less iphone users able to see sticky headers on tables with these new styles. Because some of the new styles are specific to my iphone SE 2020. So I would like some other iphone users to compare the results of the old and new styles:
- Template:Sticky header - current styles.
- User:Timeshifter/Sandbox244 - current styles. More tests and table widths.
- User:Timeshifter/Sandbox243 - testcase styles. More tests and table widths.
- User:Timeshifter/Sandbox245 - testcase styles. Narrow 3-column tables only.
- Template:Sticky header/testcases - testcase styles. Intro may be incorrect since changes have been made. Not as many table widths.
I would also like some other Android phone users to look also. And tell us if the new styles are better or worse in portrait and landscape views. Specifically, one should not have to zoom or change font size to see sticky headers. But it may be required. Table widths shouldn't matter either. But they may. Be specific when comparing the old and new styles.
The main effect of the new styles is to allow non-sortable tables to have sticky headers on desktop and cell phones. But that was never a big problem because it is easy to add class=sortable to a table. And {{sort under}} if necessary.
If the new styles affect iphone and Android phone users positively, then the new styles should go live. But if they are negatively effected by the new styles, then the new styles need to be improved. And advice from experts is requested in any case. --Timeshifter (talk) 13:40, 26 February 2024 (UTC)
- I don't have time to read through the (extensive) discussion on the template pages, but here are my observations (appropriately displayed in a table):
sandbox244 (old) | sandboxen243 & 245 (new) | |
---|---|---|
Firefox Desktop | Only sortable tables have sticky headers | All headers are properly sticky |
Firefox Android | Only sticky if the table is sortable and I (pinch) zoom out so the full width of all tables is visible (because apparently those don't scroll horizontally?) |
None sticky in portrait, all sticky in landscape |
- My viewport is 396px wide in portrait, and 760px wide in landscape. (...which is really weird scaling, because the physical display is 1080x2340. Huh.) Hopefully that's of some help. LittlePuppers (talk) 23:10, 26 February 2024 (UTC)
- @LittlePuppers: I have the same experience on my Android. Jroberson108 (talk) 23:32, 26 February 2024 (UTC)
LittlePuppers. Thanks! Am I correct to assume that all table widths worked in Firefox Android landscape without zooming? Were any of the tables wider than landscape view? I just added some columns to a couple wide tables to make them into really wide 12 or 13-column tables. Here: User:Timeshifter/Sandbox243. --Timeshifter (talk) 00:23, 27 February 2024 (UTC)
- User:Timeshifter/Sandbox243#Test sticky-header (sortable) is the only one wider on my Android Chrome landscape where I have to zoom out to make it sticky. It pushes beyond the main content area making the whole page wider, but the text is still readable. Without zooming, the edge of the screen ends inside header 9. "Test sticky-header (no caption)" too, which the edge ends inside header 12. Jroberson108 (talk) 01:15, 27 February 2024 (UTC)
- Thanks. I just increased that one to 13 columns. I created some 12 or 13-column tables for the current styles too: User:Timeshifter/Sandbox244. Does the sortable table there require zooming to be sticky in landscape? --Timeshifter (talk) 01:47, 27 February 2024 (UTC)
- It appears that with either version of the template (old or new), if there is any table on the page wider than the default width, no headers will be sticky until the page is zoomed all the way out. LittlePuppers (talk) 02:03, 27 February 2024 (UTC)
- I agree, for User:Timeshifter/Sandbox243 in landscape you have to zoom all the way out for a table to be sticky. Also, if all the sections are open (all tables in view), then no tables are sticky unless you zoom all the way out.
- For User:Timeshifter/Sandbox244, nothing is sticky except "Test sticky-header (sortable)", which requires zooming out to be sticky. Jroberson108 (talk) 02:24, 27 February 2024 (UTC)
- 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)
- 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)
I am still looking for an iphone user to look at this. TheDJ, I vaguely remember you having an iphone. And you created the sticky header gadget:
- MediaWiki:Gadget-StickyTableHeaders.css
- MediaWiki:Gadget-StickyTableHeaders.js
- Special:Preferences#mw-prefsection-gadgets
--Timeshifter (talk) 14:32, 27 February 2024 (UTC)
- I have a very busy week, I can't make any promises until the weekend. —TheDJ (talk • contribs) 10:04, 28 February 2024 (UTC)
- OK. Just bumping this to keep it out of the archives. --Timeshifter (talk) 00:01, 3 March 2024 (UTC)
- They seem to work fine on my iPhone 6s in Safari and Chrome. —Compassionate727 (T·C) 20:28, 3 March 2024 (UTC)
Compassionate727. Thanks! Did you check the the old and new styles by checking sandboxes 244 (old) and 243 (new)? It is the comparison that we need the most. Do you see sticky headers on the widest sortable tables without having to do anything special? On both sandboxes? --Timeshifter (talk) 21:24, 3 March 2024 (UTC)
- Erm, I only looked at 243. I looked at 244 just now and the headers are not sticky. (I thought that was expected?) The width of the table doesn't affect anything beyond the fact that I have a small screen and wide tables are inherently less readable anyway. —Compassionate727 (T·C) 00:12, 4 March 2024 (UTC)
Compassionate727. Thanks again. It looks like your iphone 6s screen and viewport is the exact same size as my iphone SE 2020 screen and viewport:
I fixed something on sandbox 244. Could you look again at the wide sortable table here:
- User:Timeshifter/Sandbox244#Test sticky-header (sortable)
- User:Timeshifter/Sandbox243#Test sticky-header (sortable)
On my iphone in Safari, Firefox, Chrome, Edge, and Opera: The wide sortable table is sticky in sandbox 243 and sandbox 244. --Timeshifter (talk) 12:57, 4 March 2024 (UTC)
- Sticky headers work in those sections in Chrome and Safari. In fact, they work in every section in sandbox 243, but not 244; in sandbox 244, all of the tables in sections 1, 2, 3, 7, and 8 are NOT sticky in both Safari and Chrome. —Compassionate727 (T·C) 21:12, 4 March 2024 (UTC)
- Thanks Compassionate727 for the full review of all sections! The current CSS does not work on non-sortable tables. Those are the sections in 244 that are not working for you. I get the exact same results as you.
- I am wondering if only users with small iphones get such good results. The testcase CSS is specifically pointed at iphones with the smaller viewport size found in iphone 6, 6s, 7, 8, SE 2020, and SE 2022. They all have the exact same screen size and viewport size. See:
- https://yesviz.com/iphones.php
- --Timeshifter (talk) 22:08, 4 March 2024 (UTC)
- I don't see any reason not to go live with the new styles. No issues have been found. If there are issues, then editors can simply bring it up on the talk page. Jroberson108 (talk) 07:02, 5 March 2024 (UTC)
- As I stated before, if the current styles work perfectly (for sortable tables) on all iphones, but only for smaller iphones with the proposed styles, then the new styles are not a net improvement. In that case the new styles only help with nonsortable tables. Nonsortable tables were not a serious problem in comparison. Because it is easy to make a table sortable. And sortable in a way that does not make the table wider (via {{sort under}}). Plus the new styles would break some of the tables; those with multiple header rows. We would have to go back and change the class on those tables from class=sticky-header to class=sticky-header-multi. So let's just relax and wait for some later iphone model users to show up. If the new styles work for them, then the new styles are a net benefit, and I would support them. --Timeshifter (talk) 13:00, 5 March 2024 (UTC)
- Well, FWIW, they work properly when I switch to mobile view on my laptop. Presumably if they work on both the smallest phone screen and a computer screen, they'll work on anything in between? —Compassionate727 (T·C) 15:04, 5 March 2024 (UTC)
- What brand and model is your laptop? It is possible to switch to mobile view from a desktop PC too. Link is at the bottom of all Wikipedia pages. But I don't think it gets the same results as the mobile view on a cell phone. I vaguely remember that problems ensued when I tried this method before. --Timeshifter (talk) 15:16, 5 March 2024 (UTC)
- And if they don't, then editors can easily mention it on the talk page like any normal issue, which these changes are additive. It's not a big deal. If the old styles are kept, then the same mobile fixes would need to be applied to fix Android issues, so comparing them like this is nonsensical. Also, mobile isn't the only fix, so I wouldn't get hung up on it. Jroberson108 (talk) 15:17, 5 March 2024 (UTC)
- Apparently, there is no improvement for Android sortable tables. LittlePuppers wrote: "It appears that with either version of the template (old or new), if there is any table on the page wider than the default width, no headers will be sticky until the page is zoomed all the way out." You agreed with LittlePuppers.
- We are not sure if there is any improvement for sortable tables on most iphones. We don't know whether sortable tables are sticky on most iphones (those larger than my small one) on both the current or proposed styles. --Timeshifter (talk) 15:36, 5 March 2024 (UTC)
- It seems like you don't understand the Android issues either. When tables are sticky on Android, horizontal scroll on wide tables don't work. LittlePuppers and I have both said this. Minerva adds horizontal scrolling to tables for an improved mobile experience on small screens, which occurs at Minerva's device break point (width <=720px). On Android, sticky breaks that preexisting feature making the experience worse and causes a readability issue when zooming out. It's not a matter of "no improvement", but "worse". This may be the case on other non iPhones. You mentioned that horizontal scroll still works on your iPhone, so exceptions were added for Minerva's small screens. You wanting every iPhone model in existence to test this is ridiculous. Again, if there are other issues, then it can be mentioned on the template's talk page and those changes would be additive. Jroberson108 (talk) 16:08, 5 March 2024 (UTC)
- I only want to see what is happening on any iphone larger than mine. Which is most iphones. --Timeshifter (talk) 16:23, 5 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
Request for comment from other iphone users
I am looking for iphone user(s) with a bigger screen than iphone SE 2020 or iphone 6s. I am not sure if the current CSS, or the testcase CSS, works on bigger iphones at all. Or if it does work, how well it is working. Because some of the CSS is specific to my iphone viewport. See previous discussion. This is not a voting RFC. This is just another attempt to get some input from other iphone users. I left a message awhile back at the computing reference desk, but no one showed up here from it. --Timeshifter (talk) 13:22, 4 March 2024 (UTC)
- @WP:RFC is the best means of gaining the attention of iPhone users? --Redrose64 🌹 (talk) 09:06, 5 March 2024 (UTC)]
- 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)
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
- Current styles: User:Timeshifter/Sandbox244#Test sticky-header (sortable)
- Proposed styles: User:Timeshifter/Sandbox243#Test sticky-header (sortable)
And tell us what iphone model you have. --Timeshifter (talk) 13:14, 5 March 2024 (UTC)
- @Timeshifter Tldr, tested both testcases on 14 Pro Max is working. — Paper9oll (🔔 • 📝) 06:26, 7 March 2024 (UTC)
- Thanks Paper9oll! So those wide tables had sticky headers in that specific sandbox section in both sandboxes? In both portrait and landscape orientation on your iphone?
- Tldr is fine, because those 2 sandbox sections are all I am concerned about right now. --Timeshifter (talk) 12:34, 7 March 2024 (UTC)
- @Timeshifter For portrait, both sandboxes is working. For landscape, only the first sandbox is working. — Paper9oll (🔔 • 📝) 12:47, 7 March 2024 (UTC)
- Paper9oll. "For landscape, only the first sandbox is working." Are you referring to sandbox244? --Timeshifter (talk) 13:05, 7 March 2024 (UTC)
- @Timeshifter Yes — Paper9oll (🔔 • 📝) 13:46, 7 March 2024 (UTC)
- Thanks again Paper9oll. Well, that's too bad. That means that the proposed styles are a step backwards for most iphones. I (with my smaller iphone) see the same thing you are seeing with the current styles for sortable tables (that section in sandbox244). With the current styles I see sticky headers working perfectly in sortable tables in landscape and portrait view no matter the width of the table (that section in sandbox244).
- Most iphones in use nowadays are bigger than my smaller iphone SE 2020.
- For sortable tables the proposed styles work the same as the current styles for my smaller iphone. This is because the proposed styles address my specific smaller viewport size. --Timeshifter (talk) 14:12, 7 March 2024 (UTC)
- What about "addditive" do you not comprehend? Jroberson108 (talk) 14:31, 7 March 2024 (UTC)
- What about "patience" do you not comprehend? You are approaching WP: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)]
- What about "patience" do you not comprehend? You are approaching
- What about "addditive" do you not comprehend? Jroberson108 (talk) 14:31, 7 March 2024 (UTC)
- @Paper9oll: For the page and orientation that's not sticky, can you provide the width and height from https://whatismyviewport.com/? Just the large font, not the rest. If you use multiple browsers, can you provide them for each if they differ. Jroberson108 (talk) 14:28, 7 March 2024 (UTC)
- @Jroberson108 Portrait is 375x630px and landscape is 710x292px. Browser is iOS default browser (Safari). — Paper9oll (🔔 • 📝) 14:36, 7 March 2024 (UTC)
- @Paper9oll:, can you test the one that wasn't sticky again? Jroberson108 (talk) 14:50, 7 March 2024 (UTC)
- @Jroberson108 Both are working now in both orientation. — Paper9oll (🔔 • 📝) 15:19, 7 March 2024 (UTC)
- @Paper9oll: Thanks. It just needed an exception added. Jroberson108 (talk) 15:36, 7 March 2024 (UTC)
- @Jroberson108 Both are working now in both orientation. — Paper9oll (🔔 • 📝) 15:19, 7 March 2024 (UTC)
- @Paper9oll:, can you test the one that wasn't sticky again? Jroberson108 (talk) 14:50, 7 March 2024 (UTC)
- @Jroberson108 Portrait is 375x630px and landscape is 710x292px. Browser is iOS default browser (Safari). — Paper9oll (🔔 • 📝) 14:36, 7 March 2024 (UTC)
- @Timeshifter Yes — Paper9oll (🔔 • 📝) 13:46, 7 March 2024 (UTC)
- Paper9oll. "For landscape, only the first sandbox is working." Are you referring to sandbox244? --Timeshifter (talk) 13:05, 7 March 2024 (UTC)
- @Timeshifter For portrait, both sandboxes is working. For landscape, only the first sandbox is working. — Paper9oll (🔔 • 📝) 12:47, 7 March 2024 (UTC)
I have been trying to wrap my brain around those exceptions in the proposed CSS:
screen and (width: 710px) and (orientation: landscape), screen and (width: 667px) and (orientation: landscape), screen and (width: 375px) and (orientation: portrait)
The pattern is obvious for my iphone SE 2020 (375x667px). See my viewport listed here:
I suggest substituting this for the iphone 14 Pro Max:
screen and (width: 932px) and (orientation: landscape)
If it works, then exceptions could easily be added for all iphones. By using the page linked just above. ---Timeshifter (talk) 20:07, 7 March 2024 (UTC)
- I wish it were that easy, but they gave their landscape viewport width as 710px and their test worked. No exceptions are needed for a width over 720px, so a width of 932px is already covered and redundant. If you recall, your iPhone viewport height was different from the listing too. Multiple browsers were a bit different in viewport height, but the width was consistent. Jroberson108 (talk) 20:59, 7 March 2024 (UTC)
- So this block resets the mobile table's BACK from scrollable blocks to normal tables... in orientation mode for very specific widths ... I don't get why.. why not for all widths over portrait phone sizes ? What would break on my much larger desktop screen ? I'm confused. —TheDJ (talk • contribs) 22:19, 7 March 2024 (UTC)
- @TheDJ: No issues on desktop. Basically overriding Minera's device breakpoint of <= 720px causes issues on Android and maybe some other untested devices. The issue is that the table's horizontal scroll doesn't work when sticky, which a wide table pushes beyond the main content area making the page wider, and requires zooming out to see the entire table before it's sticky making the text on the entire page more unreadable the wider the table is.
- Apparently this same issue doesn't occur on iPhone since the horizontal scroll works. The code Timeshifter posted comes from the sandbox (see comments) at the bottom and is an attempt to get it working on only iPhone at that break point, which I know widths alone aren't enough to target only iPhone, but its all we have since he wants it working. Fixing horizontal scroll on Android would be ideal, but the only solution I've found is moving the horizontal scroll to a div wrapper, which isn't possible with this template. The div wrapper solution is something I did on the COVID sticky styles that you helped fix. Jroberson108 (talk) 23:16, 7 March 2024 (UTC)
- @TheDJ: I created User:Timeshifter/Sandbox246 so I could test your sticky gadget found in gadget preferences. The sandbox has no sticky templates. On my Win 10 Pro desktop in Firefox your gadget worked on all tables there regardless of width (including the 16 column table). Except it did not work with nonsortable plain tables. It worked with sortable plain tables. And it worked with nonsortable wikitables. On my iphone it did not work in that sandbox in Safari and Firefox. In both portrait and landscape view. --Timeshifter (talk) 23:39, 7 March 2024 (UTC)
@Paper9oll: Could you check another browser besides Safari? What is its viewport here:
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):
That must be the viewport size not counting the navigation bars.
I wish there was a page listing the actual viewport sizes with the navigation bars. --Timeshifter (talk) 22:40, 7 March 2024 (UTC)
- @Timeshifter Please see below.
- Safari
- 375x630px (portrait)
- 710x292px (landscape)
- Working for both sandboxes in both orientation.
- Chrome
- 375x636px (portrait)
- 710x319px (landscape)
- Working for both sandboxes in portrait. Not working for Sandbox243 in landscape.
- Firefox
- 375x609px (portrait)
- 710x279px (landscape)
- Working for both sandboxes in both orientation.
- Edge
- 375x644px (portrait)
- 812x306px (landscape)
- Working for both sandboxes in portrait. Not working for both sandboxes in landscape, would autojump to end of page when scrolling through each tables.
- Brave
- 375x626px (portrait)
- 710x294px (landscape)
- Working for both sandboxes in both orientation.
- — Paper9oll (🔔 • 📝) 09:12, 8 March 2024 (UTC)
- Thanks Paper9oll for that thorough report! I wonder why Chrome did not work in landscape in sandbox243? The viewport width is the same as the others.
- And in Edge did it work for narrow tables in either sandbox in landscape? Please close all the sections, and then go to a section with narrow tables. We have seen this sometimes where any visible table wider than the screen causes all tables not to have sticky headers (even narrow tables on the same page).
- These 2 sandboxes only have very narrow tables:
- User:Timeshifter/Sandbox245 - Proposed styles.
- User:Timeshifter/Sandbox247 - Current styles.
- --Timeshifter (talk) 16:49, 8 March 2024 (UTC)
- @Paper9oll: Thanks for the extensive testing. Edge landscape seems to be doing some weird stuff like maximizing the use of the landscape viewport area or something, so I can't speak to that. The Chrome landscape result does seem odd since it's also 710px.
- Making it so Android still has horizontal scroll on tables and sticky works on iPhone for Minerva width <= 720px is becoming increasingly difficult. Ideally, the Android horizontal scroll should be fixed if possible so targeting only iOS isn't needed.
- Maybe TheDJ will be able to figure out a fix for the horizontal scroll or an easier way to target only iOS perhaps with a combination of
@supports (-webkit-touch-callout: none)
,@query
, and other-webkit
styles? Maybe there is a class that MediaWiki adds to thehtml
orbody
element to identify iOS that I'm unaware of? - Doesn't seem like TheDJ has the time right now, so Timeshifter it seems like your only blocker is the new styles not working on 100% of the iPhones. I can modify it so it works on all iPhones and the Android issue persists just as it does on the live styles. This way the rest of the fixes and improvements can move along. Hopefully this satisfies everyone and TheDJ can find the time one day to fix the rest. Jroberson108 (talk) 02:49, 9 March 2024 (UTC)
- I prefer to wait until the other 8 iphone viewport sizes are sticky in the proposed styles. I don't want to go backward on iphone sticky tables. Right now with the current styles they are working amazingly well. Considering how difficult it has been to get people with 2 iphone screen sizes (4.7 inch and 6.7 inch), it could take months to find people with the other 6 screen sizes, and 8 viewport sizes. As I wrote before I count 10 different iphone viewport sizes here (sort that column):
- https://yesviz.com/iphones.php - and 8 screen sizes (a different column).
- Maybe while looking for them someone figures out another solution. I think maybe we should keep the current styles, and you and/or others can concentrate solely on Android. And not worry about nonsortable tables at all. I think Android tables being sticky without problems is far more important. If we end up with Android and iphones being sticky without problems, but we can't combine that with nonsortable tables, then I am still very happy with that. It would be a great improvement. --Timeshifter (talk) 04:46, 9 March 2024 (UTC)
- @Timeshifter As requested, Sandbox245 and Sandbox247 is working on both Chrome and Edge in both orientation with no issues. @Jroberson108 As for Chrome, I forgot to mention that on Sandbox244 and Sandbox243, in landscape, it will autozoom out to fit the entire table into the screen itself as if I'm viewing it in Wikipedia's desktop view hence maybe that explain why despite having same 710px as Safari which doesn't do autozoom out to fit. — Paper9oll (🔔 • 📝) 06:43, 9 March 2024 (UTC)
- @Paper9oll: Yeah, sounds like the Chrome width changes, but you can't get the width value on the other site since it's content isn't wider than the screen. To make matters worse, that width would vary based on how wide the table is when the autozoom out happens. Jroberson108 (talk) 07:41, 9 March 2024 (UTC)
- @Timeshifter: I'm not sure what you mean by "backward on iphone sticky tables"? The change I propose on the sandbox styles is to make sticky work on all iPhones without having to add viewport widths for each device. The Android horizontal scroll issue would still exist. This part would work just like the current (live) styles, so all iPhones remain sticky.
- I'm not abandoning the fix for Android, just removing it as a blocker so the other fixes and improvements can go live. The Android fix can still be worked on and added at a later time once fixed. I'm still hoping TheDJ or someone else might have a better fix that doesn't involve device widths, whether it be now or later. But, the other parts of the sandbox styles don't depend on the Android fix. Jroberson108 (talk) 07:25, 9 March 2024 (UTC)
- @Timeshifter: I updated the sandbox styles so you can see what I'm talking about. The new styles should work on all iPhones now without needing to add viewport widths specific to devices. The same way it works on the current (live) styles. Fixing the Android horizontal scroll issue, which the issue also exists on the current (live) styles, is a secondary task. The sandbox styles can now replace the current styles. The Android fix can still be worked on separate from the rest of the styles whether it be adding the device widths back and continuing with that or some other solution. Please test and let me know if it works. Jroberson108 (talk) 14:12, 9 March 2024 (UTC)
- @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)
Testing proposed styles #2
Jroberson108 and Paper9oll. I cleared the cache of all 5 browsers on my iphone SE 2020: Safari, Edge, Firefox, Opera, and Chrome. See:
- https://www.google.com/search?q=cache+clearing+on+iphone+browsers - I have it summarized on a card I keep handy.
At User:Timeshifter/Sandbox243 the proposed styles #2 work amazingly well. All tables are sticky no matter the width. Whether in portrait or landscape orientation.
Class=sorttop is not a problem except with class=sticky-header-multi (same as the first proposed styles). This is true for both wikitable or plain table. The table is still sticky no matter the width. But the sorttop rows with that class are sticky after sorting.
@Paper9oll: Can you test in all browsers too? If you get the same results, then this is an improvement over the current styles since it works with nonsortable tables too. And so I would support going live with it.
Jroberson108 and LittlePuppers. Are your Android phones better or worse with proposed styles #2 compared to the current styles: User:Timeshifter/Sandbox244? --Timeshifter (talk) 16:04, 9 March 2024 (UTC)
- I agree that sorttop is a known issue on the current and sandbox styles, and not something fixable (it has a bug report). On Windows and Android, more things work and are sticky. On Android, the table's missing horizontal scroll and having to zoom out on wide tables for sticky to work is the same on the current and sandbox styles, so no change, as expected. No zooming out is needed if the only table that's visible is narrow and fits the portrait width like in "Test sticky-header (sortable). Narrower tables", so font size is unchanged and remains readable when sticky, which is the same in both. Jroberson108 (talk) 16:30, 9 March 2024 (UTC)
- @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)
- @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)
- @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 thesticky-header
class (used on table wikitext). Also, existing sortable tables with more than one header row (multiple) will need thesticky-header
class changed to the newsticky-header-multi
class. The large majority of the tables using this template have one header row and use thesticky-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)
- 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)
- 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)
- Class names for the new styles are fine by me. --Timeshifter (talk) 04:16, 11 March 2024 (UTC)
- The new styles went live earlier today. Jroberson108 (talk) 06:34, 12 March 2024 (UTC)
- Class names for the new styles are fine by me. --Timeshifter (talk) 04:16, 11 March 2024 (UTC)
- 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)
- 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)
- @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)
- 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)
- I'm not sure where to put this because of how long this thread is, but both styles look the same to me under the sortable section on my iPhone 14 Plus. You should also be able to simulate screen sizes under Firefox. Aaron Liu (talk) 12:36, 17 March 2024 (UTC)
- Thanks Aaron Liu, but sandboxes 243 and 244 are now using the same CSS styles since the new styles went live on March 12, 2024.
- This thread is closed. --Timeshifter (talk) 19:22, 17 March 2024 (UTC)
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)
- I'm pretty sure that behaviour originates in your browser, not in any Wiki software. -- Michael Bednarek (talk) 14:35, 10 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- I didn't know that Edge could remember edit summaries. Internet Exploder certainly couldn't. --Redrose64 🌹 (talk) 14:17, 13 March 2024 (UTC)
- @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)
- 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)
- 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)]
- 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)
- I've just unticked those and it doesn't seem to make any difference. DuncanHill (talk) 15:05, 13 March 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- Answered on that talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:40, 10 March 2024 (UTC)
- It was halved by an archive bot. However, the disputes are unresolved. Sarcelles (talk) 16:55, 11 March 2024 (UTC)
- 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)
- It was halved by an archive bot. However, the disputes are unresolved. Sarcelles (talk) 16:55, 11 March 2024 (UTC)
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)
- Looks like the maintainer is @Jon (WMF). Pinging them so you two can connect. –Novem Linguae (talk) 02:25, 11 March 2024 (UTC)
- 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)
- Hey there! I maintain this tool in my volunteer time. You can file bugs at https://github.com/jdlrobson/WikiLovesINat/issues and I'll look into them pretty swiftly. I've created https://github.com/jdlrobson/WikiLovesINat/issues/15 to make a note that I should make it easier to contact me!
- What uptime challenges are you experiencing right now? It uses the API at https://query.wikidata.org/ and I see that appears to be running slower than normal. Is that what you are referencing? Jdlrobson (talk) 22:53, 15 March 2024 (UTC)
Problem with map
Does anyone else see a problem with the infobox on WonderWorks (museum)?— Vchimpanzee • talk • contributions • 16:57, 12 March 2024 (UTC)
- 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)- Nthep, I assumed the issue was to do with Wikidata, WonderWorks (Q8031719) has coordinates. — Qwerfjkltalk 17:27, 12 March 2024 (UTC)
- 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)
- Nthep, I assumed the issue was to do with Wikidata, WonderWorks (Q8031719) has coordinates. — Qwerfjkltalk 17:27, 12 March 2024 (UTC)
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)
Problem with link to article...
When I use the link to the Wikipedia article, which is
it goes to
Ager, Yellen, and Bornstein, Inc.
Did you mean: Ager, Yellen, and Bornstein, Inc. ?
|
Starlighsky (talk) 00:18, 13 March 2024 (UTC)
- Hmm... I am not having this problem. 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)]
- @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)- Thanks! Starlighsky (talk) 01:33, 13 March 2024 (UTC)
- Probably could just drop the "inc" on an aside. Izno (talk) 16:55, 13 March 2024 (UTC)
- I dropped the period, and it is working now. Starlighsky (talk) 22:55, 13 March 2024 (UTC)
- Wikipedia:Naming conventions (companies)#Default to the most common name says to not include Inc. PrimeHunter (talk) 00:29, 14 March 2024 (UTC)
- I just did exactly that. Problem solved. Starlighsky (talk) 01:58, 14 March 2024 (UTC)
- Wikipedia:Naming conventions (companies)#Default to the most common name says to not include Inc. PrimeHunter (talk) 00:29, 14 March 2024 (UTC)
- I dropped the period, and it is working now. Starlighsky (talk) 22:55, 13 March 2024 (UTC)
Country demonyms
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
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- "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)
- 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)- 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)- Would it be possible to fix another case, while I'm here @Jonesey95? Would it be possible to add Korean as an option? I'd like to be able to use variants of these templates on categories like: Category:20th-century Korean physicians, but right now, Korean doesn't come up. It doesn't red link, but it just doesn't output a nationality at all. Mason (talk) 19:37, 15 March 2024 (UTC)
- I have added "Korean" per the good explanation at Category:Korean physicians by century. I have not tested it; please do so. – Jonesey95 (talk) 01:39, 16 March 2024 (UTC)
- The only thing that ever counts as any sort of "resolution" of a redlinked category problem is a full solution that makes the redlink go away entirely, and the problem is in no way resolved by anything short of the redlink going away entirely. Either I make the redlink go away or VPT fixes whatever technical problem is causing an autogenerated redlinked category, because if the redlink doesn't go away then the problem hasn't been resolved, and nobody gets to dictate that I have to leave redlinked category problems sitting unresolved. The existence of two isolated "joke" userspace categories that people have tried to get deleted at CFD in the past, and failed to get any sort of consensus that they were actually as problematic as redlinked mainspace categories are, is not counterevidence against the serious problems caused by redlinked mainspace categories, and a redlinked mainspace category hasn't been "resolved" in any way until it goes away. Bearcat (talk) 01:18, 17 March 2024 (UTC)
- Would it be possible to fix another case, while I'm here @Jonesey95? Would it be possible to add Korean as an option? I'd like to be able to use variants of these templates on categories like: Category:20th-century Korean physicians, but right now, Korean doesn't come up. It doesn't red link, but it just doesn't output a nationality at all. Mason (talk) 19:37, 15 March 2024 (UTC)
- 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
- 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.
- "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)
- 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)
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
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)
- 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)
- 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)
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)
- 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)
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 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)
- See Help:Template#Template_limits. ԱշոտՏՆՂ (talk) 05:28, 14 March 2024 (UTC)
- Works for me Thanks, that's exactly what it felt like, but I somehow missed that limits page. Moon darker (talk) 06:20, 14 March 2024 (UTC)
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)
- 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)
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)
- @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)
- @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)
- 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)
- I'm unable to find any watchlist settings which show the latest edit [1] to Muhammad Aurangzeb. PrimeHunter (talk) 15:39, 14 March 2024 (UTC)
- I have the same issue. Firefangledfeathers (talk / contribs) 15:44, 14 March 2024 (UTC)
- If you use this link with all filters and scripts off does it work? — xaosflux Talk 18:18, 14 March 2024 (UTC)
- I have the same issue. Firefangledfeathers (talk / contribs) 15:44, 14 March 2024 (UTC)
- I'm unable to find any watchlist settings which show the latest edit [1] to Muhammad Aurangzeb. PrimeHunter (talk) 15:39, 14 March 2024 (UTC)
- 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)
- @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)
- The page (Muhammad Aurangzeb) is appearing now in the watchlist, on its own. Strange. --Saqib (talk) 20:20, 14 March 2024 (UTC)
- Having added Muhammad Aurangzeb to my watchlist, I can replicate this. My settings are:
- At Preferences → Recent changes:
- "Group changes by page in recent changes and watchlist" - disabled
- At Preferences → Watchlist:
- "Maximum number of changes to show in watchlist:" - 250
- "Expand watchlist to show all changes, not just the most recent" - enabled
- "Use non-JavaScript interface" - enabled
- "Hide minor edits from the watchlist" - disabled
- "Hide bot edits from the watchlist" - disabled
- "Hide my edits from the watchlist" - disabled
- "Hide edits by anonymous users from the watchlist" - disabled
- "Hide edits by logged in users from the watchlist" - disabled
- "Show only likely problem edits (and hide probably good edits)" - disabled
- At Preferences → Recent changes:
- Viewing the page history shows five edits for 14 March 2024 (03:27, 06:33, 17:23, 20:19, 22:42) but with the above settings, plus on-the-fly settings for 3 days and (Article) namespace, my watchlist shows only four edits for the same date (03:27, 17:23, 20:19, 22:42). There are none missing for either 13 or 15 March. I can see nothing in the flags and tags for the 06:33 edit that might cause it to be filtered out. --Redrose64 🌹 (talk) 12:00, 15 March 2024 (UTC)
Auto-Purge
Is their any script/ template on Wikip 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)
- No. You can't force other users to perform actions. — xaosflux Talk 14:16, 14 March 2024 (UTC)
- The page refreshes to show latest version every time. It need not force anyone to perform something? ExclusiveEditor Notify Me! 06:25, 15 March 2024 (UTC)
- Pages are cached to improve performance. An auto-purge function could allow malicious users to overload the servers. -- John of Reading (talk) 07:27, 15 March 2024 (UTC)
- The page refreshes to show latest version every time. It need not force anyone to perform something? ExclusiveEditor Notify Me! 06:25, 15 March 2024 (UTC)
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)
- You might like to read Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces — Martin (MSGJ · talk) 12:38, 14 March 2024 (UTC)
- 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)- 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)- 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)- @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 intemplate:
eats some time, which is wheretp:
could be handy. Cocobb8 (💬 talk • ✏️ contribs) 14:56, 14 March 2024 (UTC)- @Cocobb8
If you're using the older Vector skinyou can use User:Ahecht/Scripts/TemplateSearch to replace{{
in the search box withTemplate:
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)- 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)- 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)- 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 onTemplate:
and then go back to{{
. It will however go back toTemplate:
once the shift key is released. Cocobb8 (💬 talk • ✏️ contribs) 18:01, 14 March 2024 (UTC)- @Cocobb8 Try it again now. I think it was fighting with Vector 2022's autocomplete function, but I figured out a way around it. --Ahecht (TALK
PAGE) 21:10, 15 March 2024 (UTC)- While Ahecht's script works in the on-Wiki search box, that workaround for the lack of a system shortcut is not a complete solution. It still leaves edit summaries and custom search boxes in browsers unsolved. -- Michael Bednarek (talk) 00:00, 16 March 2024 (UTC)
- Excellent, works perfectly now! Cocobb8 (💬 talk • ✏️ contribs) 14:28, 16 March 2024 (UTC)
- @Cocobb8 Try it again now. I think it was fighting with Vector 2022's autocomplete function, but I figured out a way around it. --Ahecht (TALK
- Installed, works nicely on Vector 2022! There is a very minor issue that when shift is still held when typing in
- 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
- Ah great thanks, but it'd be great to have something that works on all skins just like
- 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)
- That was for
t:
though, nottp:
Cocobb8 (💬 talk • ✏️ contribs) 15:26, 14 March 2024 (UTC) - 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)
- That was for
- @Cocobb8
- @Xaosflux, @Michael Bednarek: Yeah, that's what I was getting at: when editing you for sure can use
- The advantage of a namespace shortcut is that I don't have to type
- 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
- Great, thanks @MSGJ!
- @Ahecht, @MSGJ, @Michael Bednarek, @Xaosflux: Proposal created. Cocobb8 (💬 talk • ✏️ contribs) 14:40, 16 March 2024 (UTC)
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)
- 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)]
- 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)
- Pinging Ahecht, who will probably be able to figure out what I'm doing wrong at {{FS medalist/sandbox}}. – Jonesey95 (talk) 22:02, 14 March 2024 (UTC)
- @Jonesey95: Just a quick observation. {{FS medalist/sandbox}}'s arguments are being checked by Module:Flag when the module calls Module:Check for unknown parameters. These arguments will fail the check: 3, altflag, dap, dap2, flag2, link2, noflag.
- Seems like this line of code should change to "false" like the rest so the check doesn't occur for "icon". Not sure why it is different or why the check is even needed?
function p.icon(frame) return p._main(frame, 'Flagicon', 'cxxl', true) end
- Jroberson108 (talk) 05:02, 15 March 2024 (UTC)
- I somewhat understand what is happening, but I don't understand why it is happening. The Module:flag braces appear to be properly closed before they get to 3= and dap=, which are intended as parameters for {{FS medalist/sandbox}}, so I don't see why Module:flag is able to see those 3= and dap= arguments. I'm missing something. – Jonesey95 (talk) 05:32, 15 March 2024 (UTC)
- @Jonesey95: I switched it to Module:Flagg, which seems to be working. It doesn't have all the extra checks and is what the other module calls too. Jroberson108 (talk) 05:53, 15 March 2024 (UTC)
- @Jroberson108, Jonesey95:
{{#invoke:flag|icon}}
is designed to be a wrapper for {{#invoke:flagg|main}} that is a 1:1 replacement for{{flagicon}}
. The module checks for unknown parameters because the template does. If you don't want the check, you can use{{#invoke:flagg|main|cxxl}}
instead. --Ahecht (TALK
PAGE) 05:57, 15 March 2024 (UTC)
- I somewhat understand what is happening, but I don't understand why it is happening. The Module:flag braces appear to be properly closed before they get to 3= and dap=, which are intended as parameters for {{FS medalist/sandbox}}, so I don't see why Module:flag is able to see those 3= and dap= arguments. I'm missing something. – Jonesey95 (talk) 05:32, 15 March 2024 (UTC)
- Pinging Ahecht, who will probably be able to figure out what I'm doing wrong at {{FS medalist/sandbox}}. – Jonesey95 (talk) 22:02, 14 March 2024 (UTC)
- @Jonesey95 I'll look at cleaning up FS Medalist tomorrow. Currently it has {{flagicon}} nested inside two levels of #if nested inside {{unbulleted list}}, which means it's being quadruple counted towards the expand size. --Ahecht (TALK
PAGE) 06:05, 15 March 2024 (UTC)- @Jonesey95 I have a draft at Template:FS medalist/sandbox that cuts the PEIS by 60%, but it's waiting on an edit request to Module:list. --Ahecht (TALK
PAGE) 17:16, 15 March 2024 (UTC)
- @Jonesey95 I have a draft at Template:FS medalist/sandbox that cuts the PEIS by 60%, but it's waiting on an edit request to Module:list. --Ahecht (TALK
- 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)
- 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)
Can't find what's linking to this miscapitalized redirect
See this "what links here" list of articles linking to
- Look through the templates at the bottom. One of them appears to be coming from Template:NCC 1985 PBA Reinforced Conference Champions. Zaathras (talk) 01:22, 15 March 2024 (UTC)
- @WP:NAVNOREDIRECT. DuncanHill (talk) 01:41, 15 March 2024 (UTC)]
- Indeed. I thought I had looked there, but I guess I missed it. Dicklyon (talk) 01:48, 15 March 2024 (UTC)
- But seems like only one of the two is found via templates. I'm still struggling with the one remaining. Dicklyon (talk) 02:23, 15 March 2024 (UTC)
- @Dicklyon: It seems it's the word "Finals" in the {{Infobox PBA conference}} template at the top.
- Seems like it's automatic, the code for it is:
| header7 = {{#if:{{{champion|}}}{{{runner-up|}}}|{{#ifexist:{{{year}}} PBA {{{conference_name}}} Finals|[[{{{year}}} PBA {{{conference_name}}} Finals|Finals]]|Finals}}}}
- I wonder if it's alright to make that lowercase? – 2804:F14:80C6:A301:CF7:6618:2E02:A732 (talk) 03:01, 15 March 2024 (UTC)
- As to how I found it, I opened "inspect"/devtools on Chrome (F12?) and CTRL+F searched for "1985 PBA Reinforced Conference Finals" in the Elements tab until I found what element it was.
- – 2804:F14:80C6:A301:CF7:6618:2E02:A732 (talk) 03:04, 15 March 2024 (UTC)
PAGESIZE as inexpensive alternative to #ifexist parser function
Can I assume that the {{PAGESIZE}} magic word is not an expensive parser function? E.g., this is cheap:
{{PAGESIZE|Qkxjwuuu}}
→ 0
I use #ifexist when I must in templates, aware of its status as an
{{#ifeq: {{PAGESIZE:Qkxjwuuu}} | 0 | ∄ or empty | non-empty}}
⟶ ∄ or empty{{#ifeq: {{PAGESIZE:User:Mathglot/sandbox/emptypage}} | 0 | ∄ or empty | non-empty}}
⟶ ∄ or empty{{#ifeq: {{PAGESIZE:France}} | 0 | ∄ or empty | non-empty}}
⟶ non-empty
Am I missing something, or is this a good strategy for reducing the number of expensive parser functions in templates where the conditions 'pagesize=0' and 'page does not exist' are handled equivalently?
P.S. I tried alternatives: #if won't work, cuz a '0' string is true; and #ifexpr won't work, unless you formatnum-protect pagesizes > 999; #ifeq was briefest. Mathglot (talk) 03:39, 15 March 2024 (UTC)
- "Expensive" is pretty relative - the cost isn't really in counting or anything in the case of ifexist but in the fact that the system needs to make a trip to the database to know whether the page exists. The valuable thing is that ifexist will trigger updates in the page it's used on when the page you're checking for existence starts existing. IDK if that is guaranteed for PAGESIZE. I also don't know if PAGESIZE needs a DB call; it's not marked as such, but that doesn't mean much.
- That said, unless you're making a template that will be called many times a page, one or two checks for existence breaks no bank (we're allowed up to 500 expensive functions a page). Izno (talk) 04:17, 15 March 2024 (UTC)
- Thanks, yes, I know about checking the PP limit report, and some of these templates are conducive to being used in a table of lots of articles so could eat up a lot of the 500 limit, possibly exceed it although that hasn't happened yet. Also, the ones I have in mind are designed chiefly for Talk space, so it's less serious if hitting a limit does break the page, but still. Maybe Certes or xaosflux would know about the DB call question? If it's no better than #ifexist, then no point in changing these templates, but if it is better, there could be a real upside, and a tool to improve a lot of templates. Mathglot (talk) 05:13, 15 March 2024 (UTC)
- If you're not bothered about the page's existence being updated (perhaps you even want to keep a historic record of whether it existed at time of writing) then you could subst: the #ifexists (or #ifeq workaround). Then you could add pages in batches of much less than 500, so the one-off parsing would work each time. I'm not sure whether this fits with your use case. Certes (talk) 18:02, 15 March 2024 (UTC)
- Nice tip. Wouldn't work exactly for my use case, but a modification of it might. It involves a trick I saw somewhere which saves a subst without executing it the first time (maybe split up by a self-closing noinclude in the middle of it, or something like that), and then next save, it is substed. This would allow what you are saying to happen in two saves, with the first one containing a trace of the visible subst, meaning we could wait a week or whatever period, revert to the first save, let it subst again, thus saving a weekly snapshot of existence, so to speak, which might be good enough. Does that sound like it would work? Mathglot (talk) 23:29, 15 March 2024 (UTC)
- That's worth trying and may work, depending on exactly what you want to achieve. Help:Substitution#Recursive substitution may be useful, even if your case is not recursive. Certes (talk) 23:59, 15 March 2024 (UTC)
- Nice tip. Wouldn't work exactly for my use case, but a modification of it might. It involves a trick I saw somewhere which saves a subst without executing it the first time (maybe split up by a self-closing noinclude in the middle of it, or something like that), and then next save, it is substed. This would allow what you are saying to happen in two saves, with the first one containing a trace of the visible subst, meaning we could wait a week or whatever period, revert to the first save, let it subst again, thus saving a weekly snapshot of existence, so to speak, which might be good enough. Does that sound like it would work? Mathglot (talk) 23:29, 15 March 2024 (UTC)
- If you're not bothered about the page's existence being updated (perhaps you even want to keep a historic record of whether it existed at time of writing) then you could subst: the #ifexists (or #ifeq workaround). Then you could add pages in batches of much less than 500, so the one-off parsing would work each time. I'm not sure whether this fits with your use case. Certes (talk) 18:02, 15 March 2024 (UTC)
- Thanks, yes, I know about checking the PP limit report, and some of these templates are conducive to being used in a table of lots of articles so could eat up a lot of the 500 limit, possibly exceed it although that hasn't happened yet. Also, the ones I have in mind are designed chiefly for Talk space, so it's less serious if hitting a limit does break the page, but still. Maybe Certes or xaosflux would know about the DB call question? If it's no better than #ifexist, then no point in changing these templates, but if it is better, there could be a real upside, and a tool to improve a lot of templates. Mathglot (talk) 05:13, 15 March 2024 (UTC)
Well, looks like I answered my own question; PAGESIZE is no better: see PP limit report for User:Mathglot/sandbox/500 ifexist workarounds – it is maxed out at 500. Darn. Oh, well. Mathglot (talk) 05:36, 15 March 2024 (UTC)
- Added a couple of explanatory notes at Help:Magic words; feel free to adjust. Mathglot (talk) 05:54, 15 March 2024 (UTC)
- The limit is there for a reason. People trying to bypass the limit are essentially trying to break the servers. Which means that such a hole will be plugged. MediaWiki is not a generic database or generic compute platform. If you want to do very complex things, at some point you will have to write an extension and take into account the many restraints that apply to efficiently serve up data. —TheDJ (talk • contribs) 08:41, 15 March 2024 (UTC)
harvnb refs won't link back to "mother ref"
At Governor General of Canada, I've used Template:Cite canlaw for a reference (currently number four). As there's no field in that template for an author, in order to use Template:Harvard citation no brackets for subsequent references (68, 75, 77 through 80, etc) back to the same source, I tried to do as instructed at Template:Harvard citation no brackets#No author name in citation template and add |ref={{harvid}} to the canlaw template. However, in article space, none of the harvnb references link back to the "mother ref". Anyone have a clue why and how to resolve it? ₪ MIESIANIACAL 16:04, 16 March 2024 (UTC)
{{cite canlaw}}
does not support|ref=
. You can wrap the{{cite canlaw}}
template with{{wikicite}}
to work around that limitation or you can edit{{cite canlaw}}
to create an anchor ID from|ref=
.{{wikicite}}
is the simpler solution.- —Trappist the monk (talk) 16:25, 16 March 2024 (UTC)
- I got it to work. Thank you. --₪ MIESIANIACAL 17:22, 16 March 2024 (UTC)
Magic word that only removes the inline ToC
Recently, the inline TOC at
__NOTOC__
magic word. Unfortunately, this also disables the floating ToC on V22. Is there a magic word to preserve that? Or maybe a setting? Aaron Liu (talk) 18:17, 16 March 2024 (UTC)- No. Izno (talk) 22:34, 16 March 2024 (UTC)
- Why not have both? The sidebar TOC in Vector 2022, the default skin, is useful, since it stays visible when scrolling a long page and is independently scrollable. I would remove the NOTOC. – Jonesey95 (talk) 00:29, 17 March 2024 (UTC)
Custom inline talkpage CSS causing weird bugs for mobile
Continued from User_talk:Awesome_Aasim#Your_Talk_Page_Formatting:
It seems as if mobile users are not seeing the full talk page, instead getting everything collapsed to a "learn more about this page" message. I found that not only my talk page does this [2], but other stylized talk pages like [3], etc.
I get that the mobile experience sucks on Wikipedia, but this might be something that might need addressing ASAP. Can we maybe look into it? Maybe it needs a Phabricator report. Awesome Aasim 20:31, 16 March 2024 (UTC)
- @Awesome Aasim: Without looking at the details, there are three things that might be causing this: (i) the use of level 1 headings; (ii) the placement of the TOC in the third section, instead of before the first heading; (iii) the use of unclosed
<div>
tags in the first section that persist to the foot of the page. --Redrose64 🌹 (talk) 20:43, 16 March 2024 (UTC)- @Redrose64 If you see Cyberpower's talk page, which I linked to as a second example, the same notice is there. It is some sort of HTML thing happening I think that is confusing mobile. It is not happening on your talk page, either. I checked another talk page and that one functions correctly. It is some half baked piece of code that is causing this. Awesome Aasim 22:48, 16 March 2024 (UTC)
- To make things even more confusing there is no option to "read as wiki page" as previously on mobile. Awesome Aasim 22:49, 16 March 2024 (UTC)
- @Awesome Aasim: Fixed User talk:Awesome Aasim, as Redrose64 mentioned, some missing div closing tags. Jroberson108 (talk) 23:53, 16 March 2024 (UTC)
- @Jroberson108 That is not much of a "fix"; rather a bodge around a broken patch on mobile. It has been fine for mobile users until recently... BTW MW auto closes div tags, etc. at the end of pages I believe. RR's talk page BTW does not have any of this "Learn more about this page" business; I think what is supposed to happen is the first section is supposed to be displayed up there. But it isn't, and here we are.
- Maybe I can get around this with templatestyles.css for now but it still feels very bodgy. There are dozens of Wikipedian talk pages that are decorated in a similar manner to mine; if all of them are broken then it is something that should be reported to Phabricator. Awesome Aasim 01:30, 17 March 2024 (UTC)
- As an aside, autoclosing of div tags by MediaWiki hasn't been my experience in the past, for talk pages using it to put a background box around the main content area. Is that a behaviour that has changed? isaacl (talk) 02:18, 17 March 2024 (UTC)
- @Isaacl I just tried in my sandbox with this markup: {{User sandbox}}
<div>
<span>
</div>
</span> and the DOM shows them as this: <div><span></span></div>. That might not mean that it was autoclosed in the source but something is going on to fix this. Awesome Aasim 04:20, 17 March 2024 (UTC)
- Phabricator task opened: phab:T360268. Hopefully it gets fixed. Awesome Aasim 15:57, 17 March 2024 (UTC)
- @Isaacl I just tried in my sandbox with this markup: {{User sandbox}}
<div>
<span>
</div>
</span> and the DOM shows them as this: <div><span></span></div>. That might not mean that it was autoclosed in the source but something is going on to fix this. Awesome Aasim 04:20, 17 March 2024 (UTC)
- There are other issues with your page on Minerva like the "Add topic" button appearing over the categories unless the level 1 "Talk" section is opened. This may be due to having multiple level 1 headers (
<h1></h1>
), something againstWP:LEVELONESECTION. Also, if you are going to add HTML instead of wikitext, try to keep it valid and test it in the different skins. See Help:HTML in wikitext#div. BTW, the main content area you are allowed to edit isn't the end of the page, so invalid markup might affect what comes after it. Jroberson108 (talk) 03:43, 17 March 2024 (UTC)]
- As an aside, autoclosing of div tags by MediaWiki hasn't been my experience in the past, for talk pages using it to put a background box around the main content area. Is that a behaviour that has changed? isaacl (talk) 02:18, 17 March 2024 (UTC)
- @Awesome Aasim: Fixed User talk:Awesome Aasim, as Redrose64 mentioned, some missing div closing tags. Jroberson108 (talk) 23:53, 16 March 2024 (UTC)
- @Awesome Aasim: User talk:Cyberpower678 has unclosed div tags; User talk:EEng doesn't, and nor does mine. If you see a problem that affects some pages but not others, look for the common factor: in this case, the presence of extra page borders on the problem pages. --Redrose64 🌹 (talk) 00:24, 17 March 2024 (UTC)
- To make things even more confusing there is no option to "read as wiki page" as previously on mobile. Awesome Aasim 22:49, 16 March 2024 (UTC)
- @Redrose64 If you see Cyberpower's talk page, which I linked to as a second example, the same notice is there. It is some sort of HTML thing happening I think that is confusing mobile. It is not happening on your talk page, either. I checked another talk page and that one functions correctly. It is some half baked piece of code that is causing this. Awesome Aasim 22:48, 16 March 2024 (UTC)
Blank lines at bottom
I see below every page (up the last hr line) a blank space like three or maybe four blank lines. I don't know why. I'm using the old Vector interface. This happens only here in en.wiki. --ZandDev (msg) 21:56, 16 March 2024 (UTC)
- @ZandDev: Does it happen if you log out? Does it happen at https://en.wikipedia.org/wiki/Example?safemode=1? PrimeHunter (talk) 09:45, 18 March 2024 (UTC)
- @PrimeHunter: Yes this happen also if I'm logged out (so with the new Vector interface) and with safemode=1 (I had already tried that before) and also with Firefox instead of Chrome. But now I noticed that if I pin the floating index to the side the empty space at the bottom will be reduced. — ZandDev 17:39, 18 March 2024 (UTC)
- I cannot reproduce a 3-4 line gap with Vector legacy but I see it with Vector 2022 in desktop, both at Example and https://en.wikipedia.org/wiki/Example?safemode=1. The gap is only so large if the window is wide enough to show a search box at top, and both the sidebar and TOC is hidden. PrimeHunter (talk) 22:01, 18 March 2024 (UTC)
- @PrimeHunter: Yes this happen also if I'm logged out (so with the new Vector interface) and with safemode=1 (I had already tried that before) and also with Firefox instead of Chrome. But now I noticed that if I pin the floating index to the side the empty space at the bottom will be reduced. — ZandDev 17:39, 18 March 2024 (UTC)
Subtitle and jQuery, again
A while ago, I asked about how to pass a jQuery object into mw.util.addSubtilte. @Nardog suggested basically converting the object into an HTMLElement through accessing [0], which worked. However, it has a weird caveat: it duplicates the element when I run .html(newHTML) or similar functions on it, and the duplicated element will be nested under the original element. His initial suggestion of wrapping it inside a parent element does the same thing. See User:Aaron_Liu/Watchlyst_Greybar_Unsin.js#L-102 for my current implementation. Is there some way I could deduplicate this thing? Aaron Liu (talk) 21:57, 16 March 2024 (UTC)
- It looks like you're returning what is supposed to be the outer HTML in getWatchlyst(). .html() replaces the inner HTML, not the outer HTML (which you can't do without replacing the element altogether). Nardog (talk) 01:48, 17 March 2024 (UTC)
Losing vertical scroll bar when editing
In the last day or so, I've been losing the vertical scroll bar when I'm editing articles. I'm using Firefox version 123.0.1 on Windows 10. It only happens when I'm editing articles. For example, it's fine while I'm typing this message. It's not that I lose the entire window: If I make a change in the edit window, then press tab, the cursor moves to the edit summary window, even though the scroll bar has gone. It's not just the scroll bar - I can't page up or page down either. Any ideas? Thank you. 76.14.122.5 (talk) 17:43, 17 March 2024 (UTC)
- It seems to be an issue with Firefox. Using Brave works OK 76.14.122.5 (talk) 17:45, 17 March 2024 (UTC)
- The Tab key is supposed to take you to the edit summary box. That is how HTML forms operate: the tab key moves to the next focusable object in the form. --Redrose64 🌹 (talk) 23:14, 17 March 2024 (UTC)
- Yeah. I know. I mentioned that to emphasize that only the scroll bar is lost - other functionality works as intended 76.14.122.5 (talk) 04:03, 18 March 2024 (UTC)
- Sounds like something is setting
overflow-y
of<body>
to hidden. Try turning off extensions if you have any. Nardog (talk) 00:32, 18 March 2024 (UTC)- Thanks! I'll try to figure that out. I have a bunch of extensions installed, so finding out the culprit may take time. Maybe one was silently updated in the past couple of days and broke something. Thanks for the hint! --76.14.122.5 (talk) 04:06, 18 March 2024 (UTC)
- You can also try to create an account and save the below in your CSS. See also Wikipedia:Why create an account? for general benefits.
body {overflow-y:visible !important;}
- PrimeHunter (talk) 09:39, 18 March 2024 (UTC)
- Thanks! I'll try to figure that out. I have a bunch of extensions installed, so finding out the culprit may take time. Maybe one was silently updated in the past couple of days and broke something. Thanks for the hint! --76.14.122.5 (talk) 04:06, 18 March 2024 (UTC)
What if we had an AI to suggest edits along the lines of edits typically made by good editors?
What if, for example, an AI could look at the last few-thousand non-reverted mainspace edits made by the top several hundred editors across several sets of metrics (most good articles, most edits, most thanked for edits), and then look at the whole rest of the corpus and find and suggest fixes for standing issues similar to things that were fixed in other articles by the good editors? I have a hunch that an AI doing that would suggest a lot of good basic spelling, punctuation, grammar, and style fixes. BD2412 T 02:36, 18 March 2024 (UTC)
- I'd hope that 'good editors' make their edits on the basis of actually understanding what they are doing. LLMs don't have the capacity for that. If they did, we could get them to write the articles for us, and we could all retire... AndyTheGrump (talk) 04:10, 18 March 2024 (UTC)
- Sounds similar to the scripts that some already use to trace the basic and simple edits. I am not sure AI would help with more advanced edits that require remotely understanding the text, as AndyTheGrump notes, although I would be interested in the results it suggests out of pure curiosity. Do people usually give thanks for spelling, punctuation, grammar, and style fixes? CMD (talk) 04:25, 18 March 2024 (UTC)
- I do for edits to articles I've created (and I know of other editors who do this). I also might thank a user for an edit of this type that is particularly astute. I've been thanked a few times for reverting vandalism as well. I wouldn't support using AI for this sort of thing though ... there's way too much scope for false positives. If such a project was to be undertaken, each edit should be carefully reviewed by an established editor. Graham87 (talk) 06:35, 18 March 2024 (UTC)
- I use semi-automated processes (not AI) to suggest (not make) gnome edits. One of my activities is to spot links which are incongruous and might be intended for a different topic with a similar title, assess them manually, and fix if appropriate. For example, if an article links to Apple but is about iPhones rather than fruit, it might benefit from a piped link to Apple Inc. instead. AI might be able to trawl our articles for similar cases and bring them to our attention for human triage. I expect that AI might be helpful with other types of error too, the key feature being that they follow a pattern but are hard to find with existing tools. Certes (talk) 14:48, 18 March 2024 (UTC)
- I do for edits to articles I've created (and I know of other editors who do this). I also might thank a user for an edit of this type that is particularly astute. I've been thanked a few times for reverting vandalism as well. I wouldn't support using AI for this sort of thing though ... there's way too much scope for false positives. If such a project was to be undertaken, each edit should be carefully reviewed by an established editor. Graham87 (talk) 06:35, 18 March 2024 (UTC)
- My understanding is that there are existing spell, grammar, and style checkers that have long used AI models. If someone builds a tool trained on Wikipedia edits, I'm sure there will be editors interested in testing it. isaacl (talk) 06:50, 18 March 2024 (UTC)
- There's a lot of hyperbole out there. We (TINW) have been slinging around the term AI for half a century, but despite getting some extremely useful tools, we aren't there yet, and sometimes the results, including grammar and spell checking, look like artificial stupidity. Use only for suggestions and apply sanity checks. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:43, 18 March 2024 (UTC)
Tech News: 2024-12
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- The notice "Language links are at the top of the page" that appears in the Vector 2022 skin main menu has been removed now that users have learned the new location of the Language switcher. [4]
- IP info feature displays data from Spur, an IP addresses database. Previously, the only data source for this feature was MaxMind. Now, IP info is more useful for patrollers. [5]
- The Toolforge Grid Engine services have been shut down after the final migration process from Grid Engine to Kubernetes. [6][7][8]
- Communities can now customize the default reasons for undeleting a page by creating MediaWiki:Undelete-comment-dropdown. [9]
Problems
- RevisionSlider is an interface to interactively browse a page's history. Users in right-to-left languages reported RevisionSlider reacting wrong to mouse clicks. This should be fixed now. [10]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 19 March. It will be on non-Wikipedia wikis and some Wikipedias from 20 March. It will be on all wikis from 21 March (calendar). [11][12]
- All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. [13][14]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 17:37, 18 March 2024 (UTC)
AFD Stats 500 Internal Server Error
AFD stats https://afdstats.toolforge.org/afdstats.py does not load but says "Stats 500 Internal Server Error". Since I have no issues with my system, I am assuming this is a toolforge issue to be dealt with. — Maile (talk) 17:37, 18 March 2024 (UTC)
- Also left this message at Enterprisey. — Maile (talk) 18:20, 18 March 2024 (UTC)