Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPT)
 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

Enhanced editnotice loader

[edit]

I worked on a module that would serve as an enhanced editnotice loader for Wikipedia. See testwiki:Module:Editnotice_load and Module:Editnotice load (which is an exact copy). Features include category editnotices, better group notices, and editnotices by page ID (which would reduce the need to move pages around).

I want to get further feedback on this loader before it inevitably gets implemented. Please check out the testwiki. It should be backwards compatible with the way we do things, but I would like checks for this first.

If this is to be implemented, there will need to be a couple of changes made, including to:

This would make the editnotice loader much more robust.

Immediately, in preparation for this, I would consider adding the following category editnotices templates:

{{BLP editintro}}

{{Disambig editintro}}

Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)[reply]

Some documentation on how it works from a user's perspective would be helpful, in order to understand the context and how it would be used in practice, including how security restrictions are enforced. On a side note, I'm not sure that its deployment is "inevitable". isaacl (talk) 22:03, 9 September 2024 (UTC)[reply]
I have some testcases on testwiki. For best results, view when logged out and inspect the HTML when logged in.
testwiki:Taylor Swift should be a good example of me getting category editnotices working. testwiki:Protected title and testwiki:Protected title2 show the protection editnotice on both the create screen and on the "does not exist" screen when a title is protected from creation for other reasons.
testwiki:Special:EditPage/A should show the page notice from testwiki:Template:Editnotices/PageID/54370 (which is for A). You can also see I renamed previous "page notice"s to "title notice"s because the way page notices are bound to currently are actually to titles, not pages. The new "page notice" will remain bound to a specific page because it uses PageID. There will be no need to update the title notices for pages that exist. On the other hand, for pages that don't exist, the title notice will need to be kept up to date. Awesome Aasim 04:01, 10 September 2024 (UTC)[reply]
I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)[reply]
The editnotices live in the same pseudo-space: Template:Editnotices/. See testwiki:Module:Editnotice load/config.
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. Awesome Aasim 13:16, 10 September 2024 (UTC)[reply]
OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)[reply]
There is less ambiguity in how they are handled. For example, on testwiki:Template:A/B/C/D/E, there are five different group editnotices that can be created. So if there is a page where it is desirable that the group Template:A/B needs one group notice, and Template:A/B/C needs another group notice, and Template:A/B/D needs another group notice, that can now be done; there will be one common group notice and two separate group notices for subpages. Awesome Aasim 19:21, 11 September 2024 (UTC)[reply]
I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories.
Immediately, in preparation for this, I would consider adding the following category editnotices templates this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)[reply]
I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.
Do you have an idea for a Scribunto test runner for Module:Editnotice load to ensure that everything works with demo editnotices? Awesome Aasim 16:53, 13 September 2024 (UTC)[reply]

I haven't noticed any bugs or regressions yet, if someone could take a second look at my code maybe then we will be able to identify potential problems. Awesome Aasim 12:52, 2 October 2024 (UTC)[reply]

I submitted an edit request. I think this is something that could be botted by an admin opening up 8 edit windows and then saving all of the proposed changes at once. I have done this before, it gets annoying when you get rate limited but it is not impossible. Awesome Aasim 20:05, 8 October 2024 (UTC)[reply]
[edit]

On Wikivoyage, that article is just mediocre quality. There should be no start there. I am not sure how to remove it and what caused the error (could it happen for other articles?). Piotrus at Hanyang| reply here 04:20, 26 September 2024 (UTC)[reply]

It was added to Wikidata in this revision. Not sure why as looking through the history of wikivoyage:Kaesong it was never star quality.  novov talk edits 05:58, 26 September 2024 (UTC)[reply]
@Hanyangprofessor2: The star is because of the "badge" (a little rosette) at d:Q109079#sitelinks-wikivoyage. As noted above, this was set by Dexbot (talk · contribs) almost ten years ago; you would need to ask its botop (Ladsgroup) what the mechanism is that triggered this amendment. If it really is wrong, these "badges" appear to be user-editable. --Redrose64 🌹 (talk) 15:15, 26 September 2024 (UTC)[reply]
They aren’t; saving the changes to them is limited to certain user groups.  novov talk edits 22:59, 26 September 2024 (UTC)[reply]
@Ikan Kekek FYI, and maybe you know who to ping. Or report this to WV Traveller's Pub, I am not sure how serious this issue is, but I think the star should not be there for 'usuable' articles. Piotrus at Hanyang| reply here 07:21, 27 September 2024 (UTC)[reply]
I don't understand the problem. It's starred on Wikidata? Best to discuss that there, I guess. I don't normally edit Wikidata. You could bring this up in the voy:Wikivoyage:Travellers' pub. Ikan Kekek (talk) 15:35, 27 September 2024 (UTC)[reply]
@Hanyangprofessor2 The bot added the badge ten years ago because at least back then this revision to be exact had voy:Template:Usablecity. Note that the badge was added for "recommended article" [1] hence the silver (not gold). There are many badges. You should be able to see the list of page that have badges in voy:Special:PagesWithBadges Ladsgroupoverleg 10:26, 27 September 2024 (UTC)[reply]
And the current version of voy:Kaesong#Go next still has {{usablecity}}. This is therefore a matter for Wikivoyage, and not our problem at all. --Redrose64 🌹 (talk) 18:06, 27 September 2024 (UTC)[reply]
@Ikan Kekek @Redrose64 The issue is that usable article on Wikivoyage are just middle-level artices (see voy:Wikivoyage:Article status). A star should denote an equivalent of a Featured article - on Wikivoyage that would be a Star-class article. A Good Article equivalent there would be a Guide (which even uses the GA green cross). Having Featured Article-lookalike barnstars for Wikivoyage usable articles, which are equivalent to our B- or C- class articles, makes no sense and is arguably actively misleading. Piotrus at Hanyang| reply here 03:16, 30 September 2024 (UTC)[reply]
PS. And it is a problem for us (not for Wikivoyage), because it is us (English Wikipedia) that has misleading indicators suggesting that our sister project article is high quality, when it is not. Wikivoyage has correctly identified the article as a middle-level (usuable) article, but we are incorrectly starring them as high-level articles. Piotrus at Hanyang| reply here 03:18, 30 September 2024 (UTC)[reply]
PPS. Compare to Hiroshima, which is a star-level article on Wikivoyage, and is correctly tagged with that project's yellow star in our article. Why are we tagging Wikivoyage usable articles at all, and why are we using Featured Article symbol instead of the Wikivoyage blue circle (which is the symbol for their usable articles)? At minimum, the symbol for usable content should be fixed (from FA star to blue circle), and I'd strongly suggest removing any symbols for that class (which is below GA-level equivalent). I hope the issue is now clearer? Piotrus at Hanyang| reply here 03:21, 30 September 2024 (UTC)[reply]
@Hanyangprofessor2: The stars, discs etc. (of whatever colour) are added by mw:Extension:WikimediaBadges based on settings in Wikidata. If the extension is faulty, file a ticket at phab:. If Wikidata has the wrong settings, fix them, or find out at Wikidata why their bots are using imperfect algorithms. Whatever the problem is, it's still not our fault. --Redrose64 🌹 (talk) 20:14, 30 September 2024 (UTC)[reply]
@Redrose64 But it is our problem, and I don't have time to learn the extension details to fix it. I am just reporting it here, so those more familiar with the issue can investigate it and fix it.
I will ping editors who have edited the mediawiki extension page you linked: @MarcoAurelio @Eisheeta Piotrus at Hanyang| reply here 06:53, 2 October 2024 (UTC)[reply]
@Hanyangprofessor2: How can it be out problem when (a) there is no fault at English Wikipedia and (b) there is nothing that can be done at English Wikipedia to alter the situation? As for MarcoAurelio and Eisheeta, they will probably tell you exactly what I have already said: that the extension displays a star according to whatever is set on Wikidata. Have you raised any discussions at either Wikidata itself, or at Wikivoyage? --Redrose64 🌹 (talk) 09:47, 2 October 2024 (UTC)[reply]
@Redrose64 It is our problem because we are displaying misleading information to our readers. I am not saying it is our fault, I am not saying it is anyone's fault (we are all well meaning volunteers here), but it is not Wikivoyage of Wikidata problem, because the error (which may be related to some bad tool they use or used) affects us, not them. And as I said, I don't know where else to raise this problem, and it is us who should care the most about it, since we (our readers) are the ones most affected. Piotrus at Hanyang| reply here 07:34, 3 October 2024 (UTC)[reply]
(edit conflict) @Hanyangprofessor2: Two users above have suggested voy:Wikivoyage:Travellers' pub; you have posted there before regarding other matters, so you are aware of its existence. Then there is d:Wikidata:Project chat. Now please stop pretending that this is an English Wikipedia problem when all we are doing is reflecting data that is stored elsewhere. This is like reading in your newspaper about some unpleasant situation in a foreign country and expecting your local newsagent to do something about it. --Redrose64 🌹 (talk) 16:15, 3 October 2024 (UTC)[reply]
As I explained to you, I don't believe it is Wikivoyage problem at all. Wikidata, to a small degree (because some data is hosted there). But this is primarily our problem; it doesn't matter where the data is stored - it is our project which displays misleading information. I do not understand why you are fine with our website displaying errors. Piotrus at Hanyang| reply here 03:57, 4 October 2024 (UTC)[reply]
Our website displays millions of errors. This is a tiny minor detail that in no way compromises the integrity of English Wikipedia. To quote Jonesey95: The problem is that a silver star is used for both "Good" (second-tier) and "Recommended" (i.e. third-tier, the level below Good quality) in the extension. Please note those words in the extension. Nothing that Jonesey95 has written demonstrates that it is our problem at all. Jonesey95 has restated - in different words - information that was already provided to you earlier in this thread. Sure, we display that little silver star. But the code to display that star is part of the MediaWiki software, which is shared by all WMF wikis. --Redrose64 🌹 (talk) 07:34, 4 October 2024 (UTC)[reply]
Feel free to disagree, but I believe that removing even one error is a good thing. I don't feel that the fact that our website has millions of errors is ok. Piotrus at Hanyang| reply here 03:06, 5 October 2024 (UTC)[reply]

I did a bunch of digging to see what might be happening here. So far I have found a page explaining that on en.WikiVoyage, they have Star (=en.WP FA), Guide (=en.WP GA) and Usable (no en.WP equivalent?) articles. Then I found this October 2014 bot request on Wikidata listing those same three article statuses and asking for Dexbot to assign badges based on those statuses. The bot's edit adding the "recommended article" status for en.Wikivoyage to Kaesong on Wikidata happened in that same time frame. So far, it appears that everything is working as designed. Then I found this CSS page, part of the mw:Extension:WikimediaBadges extension, that assigns star images. It assigns a gold star to Featured articles, and a silver star to articles flagged with either "goodarticle" or "recommendedarticle" status.

As far as I know, en.WP does not have a "recommended article" status (I'm not seeing anything comparable in the table at {{Article history}}).

TL;DR: The "recommended" (i.e. third-tier) tag next to en.Wikivoyage on Kaesong on Wikidata appears to be correct, according to the statuses used on en.Wikivoyage. The problem is that a silver star is used for both "Good" (second-tier) and "Recommended" (i.e. third-tier, the level below Good quality) in the extension.

It seems to me that if a "recommended article" is a third tier, it should get a bronze star (to be in line with gold and silver). That might mess up the star color on other WMF wikis, though. Since the extension is not documented well (see T212020), and I haven't found a table or map that shows the different statuses on each monitored site, it is difficult to know whether changing "recommended article" to bronze in the CSS file would fix a problem here but break something on another site. – Jonesey95 (talk) 16:07, 3 October 2024 (UTC)[reply]

It turns out that there is an existing Phabricator feature request at T189374 to make this change. If anyone here wants to make this change happen and knows how to actually upload a proposed change to gerrit/github or whatever site is used, be my guest. – Jonesey95 (talk) 16:24, 3 October 2024 (UTC)[reply]
Pinging Krinkle and Ladsgroup, who have contributed code to this extension. – Jonesey95 (talk) 16:29, 3 October 2024 (UTC)[reply]
Badges to my knowledge are owned by WMDE. Please contact wikidata team. Ladsgroupoverleg 18:01, 3 October 2024 (UTC)[reply]
How? A link to the appropriate discussion page would be helpful. I find Wikidata impenetrable. – Jonesey95 (talk) 21:09, 3 October 2024 (UTC)[reply]
@Jonesey95: d:Wikidata:Project chat, as I mentioned earlier. --Redrose64 🌹 (talk) 22:50, 3 October 2024 (UTC)[reply]
Thanks. I have posted there. We'll see if anyone is able to help from there. – Jonesey95 (talk) 23:33, 3 October 2024 (UTC)[reply]
@Jonesey95 Thank you for investigating it and trying to actually help, rather than brushing this off. I expect some readers of English Wikipedia are confused, but they likely don't even know (or care enough) to report this. Piotrus at Hanyang| reply here 03:55, 4 October 2024 (UTC)[reply]
  • Do any of the regular (or irregular) watchers at VPT feel that this is an English Wikipedia problem? Or that it is not? Please state one way or the other. --Redrose64 🌹 (talk) 07:53, 4 October 2024 (UTC)[reply]
    It's an en.WP problem in that we are affected by it. If my neighbor's car alarm is going off in the middle of the night, it's a problem for me in that I can't sleep, and it's a problem for my spouse in that my spouse has to listen to me complain about it. I would not be surprised if other WMF sites are affected by this doubling-up of second-tier and third-tier article quality indicators; if so, it is a problem on many sites. The origin of the problem appears to be in a Wikimedia (or WMDE, whatever the difference is) extension. Problems that manifest on en.WP are often caused by code that is outside of our immediate control. – Jonesey95 (talk) 12:45, 4 October 2024 (UTC)[reply]
    I don't see a star at all, even if I log out and view with a majority desktop browser, or go into mobile mode. Does it need a gadget or preference enabled to see, or am I just missing it? But I agree with Jonesey95 that it's our problem if it's displaying on our site; and we should fix it locally if a global fix is impractical or undesirable. —Cryptic 13:22, 4 October 2024 (UTC)[reply]
    so you can either get some earplugs (fix locally) but this just masks the problem, it doesn't make it go away. Or, you go round to your neighbour, tell them they have a problem with their car and ask them to fix their car (global fix). Here, we should be going to the neighbour. Nthep (talk) 14:10, 4 October 2024 (UTC)[reply]
    Yes, getting your neighbour to fix it is best, but if the alarm keeps going off night after night, you wear earplugs in the meantime. —Cryptic 15:16, 4 October 2024 (UTC)[reply]
    The trouble is, we forget to remove the earplugs after the neighbour fixes the car. Nthep (talk) 17:48, 4 October 2024 (UTC)[reply]
    The stars are not visible in Vector 2022 due to a bug. Try forcing Vector Legacy: https://en.wikipedia.org/wiki/Kaesong?useskin=vector and note the silver star next to WikiVoyage in the left-side menus, under "In other projects". That silver star should be bronze, because Kaesong is a "Usable" (third-tier) article on WikiVoyage. This is admittedly a trivial matter, but we are at VPT .... – Jonesey95 (talk) 15:10, 4 October 2024 (UTC)[reply]
    Thank you. .badge-recommendedarticle.badge-recommendedarticle { list-style-image: url(https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Rekommenderad_gr%C3%B6n.svg/12px-Rekommenderad_gr%C3%B6n.svg.png); } in your CSS changes it to the green star from the phab ticket. Obviously that isn't usable sitewide as-is - the file needs to be protected, it should be uploaded at the proper size instead of relying on the scaled-down version which will eventually go away, and like you say above bronze is probably a better choice - but it's enough to show we don't have to wait on an upstream fix, which may or may not ever happen. —Cryptic 16:19, 4 October 2024 (UTC)[reply]
    Sorry for being away from this thread for a while. None of this is a Wikivoyage problem, and there's nothing that we can do about it at Wikivoyage, as far as I can tell. It seems to be a Wikidata problem. Ikan Kekek (talk) 20:30, 6 October 2024 (UTC)[reply]
    I'd rephrase it as "it's a Wikipedia problem caused by Wikidata". Piotr Konieczny aka Prokonsul Piotrus| reply here 06:03, 7 October 2024 (UTC)[reply]

Earwigs copyvio tool is down

[edit]

What it says on the tin. The Earwig is aware of this. Whenever anyone tries to use the tool, they get this message most of the time: An error occurred while using the search engine (Google Error: HTTP Error 429: Too Many Requests). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine.

Obviously, there's a bit of tomfoolery around hitting the limit, which is apparently shared by all users of Wikipedia. There was some discussion in the WMF section of the pump a few weeks back about what the WMF can do about it. I'm mostly interested in what we can do in the meantime while it gets fixed. I dream of horses (Hoofprints) (Neigh at me) 00:56, 29 September 2024 (UTC)[reply]

You could do your own search engine search for snippets of text from the article. One sentence from each paragraph should give an indication of problems. And you can tick the box on the tool to limit the check. Graeme Bartlett (talk) 05:49, 29 September 2024 (UTC)[reply]
This is the message I get every time I try to use Earwig check tool since early 2024. It's always over the limit. I've asked Earwig about it multiple times and I think the problem is that bots can use it and they are causing it to hit its daily limit pretty early in the day. I wish bots could get booted of so that regular editors would have access to the tool but I have yet to see any change. I don't even try to use it any more. Liz Read! Talk! 22:43, 29 September 2024 (UTC)[reply]
It does work for me quite often, probably as I am in a different time zone. You may have to await the end of the "day", and try again. Graeme Bartlett (talk) 22:47, 29 September 2024 (UTC)[reply]
@Liz: There's a message from Chlod saying The Right People are aware and working on a way to authenticate. I'm sure that'll boot the bots off.
@Graeme Bartlett: I was thinking more of an alternative tool that we can use instead? Like, how does CopyPatrol work? I dream of horses (Hoofprints) (Neigh at me) 04:57, 2 October 2024 (UTC)[reply]
Perhaps the bot behind this tool is what is exhausting Google? I don't know/ https://meta.wikimedia.org/wiki/CopyPatrol It also uses turnitin, and you can tick that box on earwig. But its findings show less than Google search. Graeme Bartlett (talk) 06:07, 2 October 2024 (UTC)[reply]
There is some documentation that indicates that a bot is going through recent changes and marking the likely copyright cases to copypatrol. Looking at a single page, surfacing results for that page like that is less traffic than letting several users query that same page. I would say Copypatrol should be used for english wikipedia and other supported projects, but earwigs tool when copypatrol does not support the project. Snævar (talk) 01:15, 3 October 2024 (UTC)[reply]
@Graeme Bartlett and @Snævar: CopyPatrol uses TurnItIn, not google (unlike Earwig, which uses both Google and TurnItIn). Probably why it shows less (which is a bit of a problem), but perhaps it is a stop gap measure. My main concern about CopyPatrol is that it's more useful for individual edits and not an entire article. I dream of horses (Hoofprints) (Neigh at me) 22:07, 3 October 2024 (UTC)[reply]
Sigh... Where is this guesswork coming from? meta:CopyPatrol says it uss User:EranBot that uses both google trough Earwin and Turnitin. Read both links. Could you stop this guesswork nonesence and stick to facts? You are starting to annoy me. Also if you put an diff into earwigs tool it checks the whole article, not just the diff in question. Do not just repeat nonesence when proven otherwise. Snævar (talk) 09:37, 8 October 2024 (UTC)[reply]
[edit]

I was doing some cleanup on Lockheed Martin shooting and came across an situation that I have never encountered before. The Internet Archive links at least on this article now seem to be failing. When I went to the saved URLs, the content that had been saved in the past came up in passing but then a different link/usurped content? for widgetbox(dot)com came up/took over. Has anyone else come across a similar issue? Is this just The Meridian Star news articles? And hey, for any of the lurkers around here who knows what's what etc, apologies in advance if I've possibly posted this issue in the wrong place, I just couldn't figure out where this might belong. No snark please, I just figured I better ask somewhere around here. - Thanks, Shearonink (talk) 18:02, 29 September 2024 (UTC)[reply]

Shearonink, are you referring to this? — Qwerfjkltalk 19:51, 29 September 2024 (UTC)[reply]
A couple of things happen.
When I click though the link that you posted above I get a result saying the "page doesn't exist..."
BUT when I click on Ref #7/"Three years later" in the Lockheed Martin shooting from the Meridian Star ->>https://web.archive.org/web/20120314014942/http://meridianstar.com/local/x681061768/Lockheed-Martin-Three-years-later?keyword=leadpicturestory I get THIS wacky "widgetserver" result-->>>https://web.archive.org/web/20120327105127/http://cdn.widgetserver.com/
Hope i've explained it...I'm kind of flummoxed by all this. I even tried to do a search for both of the Meridian Star articles at Newspapers.com and also at the paper's website but couldn't get any results. - Shearonink (talk) 22:04, 29 September 2024 (UTC)[reply]
Looks like a widget that the page included forces a redirect for some reason. Anyway I've changed the reference to use an archive from a different date, that doesn't seem to have that issue. --Chris 08:22, 30 September 2024 (UTC)[reply]
Thanks Chris G. I had never seen a redirect like that, basically hidden within a webarchive URL. Seems like a usurpation... I'll remove the dead link template. I was vaguely thinking it had something to do with recent news about the Wayback Machine being sued?... - Shearonink (talk) 14:33, 30 September 2024 (UTC)[reply]
Wayback Machine itself @Shearoninkwas not relevant in the lawsuit. Rather Internet Archive was sued for its book lending program, so completely unrelated. Based on above discussions, rate limits are issue with Google itself. ~ 🦝 Shushugah (he/him • talk) 22:12, 3 October 2024 (UTC)[reply]

We need to rethink the extended confirmed user right.

[edit]

Either have a user right that is given only to trusted people without any additional rights attached to it (and with a matching level of protection) or make extended confirmed be given manually. There are too many people gaming the system to be hateful pricks on editors' user pages or to push a POV on CTOPs. LilianaUwU (talk / contributions) 21:59, 30 September 2024 (UTC)[reply]

That's more of a policy/proposal type question, not a technical one. Izno (talk) 22:01, 30 September 2024 (UTC)[reply]
@LilianaUwU You don't need to have extended confirm to edit someone elses user page. You can do that logged out. Trust me. I know. My user page was vandalized repeatedly before it was semi'd indefinitely. I dream of horses (Hoofprints) (Neigh at me) 22:01, 3 October 2024 (UTC)[reply]
I'm talking about my own user page, which is ECP'd and yet gets gamers all the time. LilianaUwU (talk / contributions) 23:08, 3 October 2024 (UTC)[reply]
There can't be that many of them, according to Wikipedia:User access levels there are only 72,041 extended confirmed users total. Compare that to the 2.38 million autoconfirmed users and it already looks like a pretty severe standard. In terms of the few hateful jerks who game the system... Whatever the system is they're going to game/abuse it, but that doesn't mean why shouldn't try to make their lives harder. On the technical side we could go to one year and 1,000 edits without too much disruption, thats probably enough to keep the jerks at bay. Horse Eye's Back (talk) 22:11, 3 October 2024 (UTC)[reply]

Pageviews of wiki.phtml

[edit]

Yesterday's topviews list (1 October 2024) has an unusual item I haven't seen before: with 96,959 views, the 24th-most-viewed page is supposedly wiki.phtml, a page that's apparently never existed. It was the 124th-most-viewed the day before. Wondering what's driving traffic (the Internet Archive has saved the URL a few times over the years) and how views are tracked for a non-existent page. Hameltion (talk | contribs) 22:04, 2 October 2024 (UTC)[reply]

Not an answer as to why it's listed, but instead of for example w/index.php?title=Pete_Rose, you can do w/wiki.phtml?title=Pete_Rose. – 2804:F1...93:F040 (talk) 22:27, 2 October 2024 (UTC)[reply]
It may be irrelevant but as an admin I can see two deleted revisions from July 2004. The first only said [[Wikipedia:Dewey Decimal System/103|103]]. The second a minute later added {{delete}}. The oldest entries at Special:Log/delete are from December 2004. PrimeHunter (talk) 23:18, 2 October 2024 (UTC)[reply]
Interesting about now-unlogged deletions ... 2 Oct recorded another 90,551 views yesterday, but massviews based on wikilinks (using the redlink here at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)) sees only 3 views all-time. Can't seem to reproduce any views at all for other redlinks this way, though. Hameltion (talk | contribs) 17:20, 3 October 2024 (UTC)[reply]
Just sounds like a bot that needs to be told to find something else to hit. Izno (talk) 23:23, 2 October 2024 (UTC)[reply]
Yeah it was the old URL before index.php; see a random example of its use. @PrimeHunter:, it's listed in the first july 2004 deletion log. Graham87 (talk) 01:01, 3 October 2024 (UTC)[reply]
Thanks. I have linked Wikipedia:Historical archive/Logs/Deletion log in MediaWiki:Dellogpagetext which is displayed at Special:Log/delete.[2] PrimeHunter (talk) 01:48, 3 October 2024 (UTC)[reply]
@PrimeHunter: Thanks but sorry, as the person who restored the old deletion logs back in 2016 (see below), I'm not comfortable with that page being linked so prominently (it actually never has been linked in that system message until now). My two main reasons are that (a) the number of people who'll need to make use of it will be vastly lower than the number of people who will misunderstand it and/or try to mess up related links (I have personal experience with this sort of thing from way back in 2007 with a similar situation relating to the old block log ) and (b) the deletion reasons often quoted the original text of the page, meaning that they contain a lot of personal information and general nastiness. The latter point is the reason many of the deletion logs were deleted between 2006 and 2016; it's quite a story how I came to restore them. I'll therefore partially revert your edit to the MediaWiki namespace page, citing this comment. Graham87 (talk) 06:17, 3 October 2024 (UTC)[reply]
As a compromise, I'm going to add a note about the old deletion logs to an interface message that appears when undeleting pages, MediaWiki:Undeletehistory, as you'd only see a list of deleted edits without a deletion log if you're an admin ... and then only for pages deleted on or after 8 June 2004. Graham87 (talk) 06:53, 3 October 2024 (UTC)[reply]
@Graham87: OK. The search box on Wikipedia:Historical archive/Logs/Deletion log fails because the prefix is wrong after page moves. Do you want it fixed or should the search box be removed to make the logs less accessible? PrimeHunter (talk) 11:53, 3 October 2024 (UTC)[reply]
@PrimeHunter: Thanks for pointing that out ... I've fixed it. Graham87 (talk) 12:20, 3 October 2024 (UTC)[reply]

Auto-creation of a local account failed

[edit]

When trying to login to another Wikipedia for which I don't have a local account like https://mos.wikipedia.org I get the error:

Auto-creation of a local account failed: Cannot create account: The username is already in use. Please pick another name.

Any workaround? Killarnee (talk) 01:58, 3 October 2024 (UTC)[reply]

@Killarnee: Have you both tried when you were already logged in at another wiki and when you logged out first? PrimeHunter (talk) 02:18, 3 October 2024 (UTC)[reply]
@Dreamy Jazz maybe relevant to your existence given what you're working on. Izno (talk) 03:30, 3 October 2024 (UTC)[reply]
I don't think so AFAIK. It appears to be related to merging wikitech accounts into SUL. Dreamy Jazz talk to me | my contributions 11:57, 6 October 2024 (UTC)[reply]
It works for me. Special:CentralAuth/Killarnee says: "Global group: Two-factor authentication testers". Maybe that causes problems. The error message sounds like something that shouldn't happen but it's apparently a combination where MediaWiki:Authmanager-authn-autocreate-failed is called with MediaWiki:Centralauth-account-unattached-exists. The Killarnee account does not exist at https://mos.wikipedia.org but the bottom of Special:CentralAuth/Killarnee shows an unattached account at wikitech:User:Killarnee. This may be relevant. If it's your account then can you merge it at Special:MergeAccount or wikitech:Special:MergeAccount? PrimeHunter (talk) 04:13, 3 October 2024 (UTC)[reply]
It was the Wikitech account and after the merge it works. Thanks a lot. Killarnee (talk) 12:05, 3 October 2024 (UTC)[reply]

Watchlist icon issue on Mobile

[edit]

Hey, I am facing an issue with mobile editing. I am unable to see the ‘Star’ icon after adding an article to my watchlist. The spot where it used to be is now just a blank white space. When I click there, it works and removes the article from the watchlist, and the star appears. However, when I add the article to the watchlist again, the star disappears. This issue is not occurring on desktops. Can anyone else editing through mobile confirm this? GrabUp - Talk 12:27, 3 October 2024 (UTC)[reply]

I was just going to post a question about this. I would be interested in an answer about the 'invisible' watchlist star. Thanks for posting this @GrabUp:. Knitsey (talk) 17:31, 3 October 2024 (UTC)[reply]
@Knitsey: Also, my notification icon is getting invisible whenever someone like you tags or mentions me. What’s going on, lol? GrabUp - Talk 17:34, 3 October 2024 (UTC)[reply]
I've just noticed that. I was tagged in a post and my icon was red but disappeared after I looked at it, another blank space. Knitsey (talk) 17:37, 3 October 2024 (UTC)[reply]
Correction, when I have a notification, it shows up as white background with slighty off white mumber of notifications. (The red notification has gone). Knitsey (talk) 17:40, 3 October 2024 (UTC)[reply]
Yes, same. GrabUp - Talk 17:44, 3 October 2024 (UTC)[reply]
@Jon (WMF) Izno (talk) 17:36, 3 October 2024 (UTC)[reply]
It looks like this is tracked at phab:T376359. Thanks. Quiddity (WMF) (talk) 18:09, 3 October 2024 (UTC)[reply]
New task created (phab:T376414) for the Notification background color bug. Quiddity (WMF) (talk) 18:29, 3 October 2024 (UTC)[reply]
[edit]

The issues with links that shouldn't be blue being blue are thankfully fixed, but now there is a new problem. All categories, links in talk page banners, and links in maintenance banners are now underlined at all times. This is not the case on the desktop version. Is this intended, or is it another visual bug? Thanks, QuicoleJR (talk) 14:10, 3 October 2024 (UTC)[reply]

I've just seen this, appears to be a new development today. AusLondonder (talk) 17:28, 3 October 2024 (UTC)[reply]
It looks like one aspect of this is covered by phab:T376146. I'll followup with the devs to see if that task covers these other aspects, or if they need separate tasks. Thanks for reporting. Quiddity (WMF) (talk) 17:37, 3 October 2024 (UTC)[reply]

Interlang bug

[edit]

So I'm not going to need a photo for this bug since it's on my user page. When going on my user page, do you see an interlanguage link in French? If so, then click on it and it'll go to a random French bombing article. The issue is that my user page isn't on the wikidata, which is normally how you link languages. I was translating that article, and for some reason it thinks my user page is the article I translated. SirMemeGod14:34, 3 October 2024 (UTC)[reply]

@Sir MemeGod You had one of the old-style of interlanguage links on your user page. To include a normal link to a page on another language, you have to precede it with a colon i.e. [[:fr:Attentat du 25 juillet 1995 à la gare de Saint-Michel du RER B]]. I fixed it for you. the wub "?!" 14:53, 3 October 2024 (UTC)[reply]
@Sir MemeGod: It's not a bug, it's described at WP:LOCALLINK, and there are times when it's desirable. For example, see the languages list for User:Redrose64 - this is all the Wikis that I have edited over the last fifteen years. If I had added these to Wikidata, the same long list would be shown on my home pages at dozens of other Wikis - but I don't want that, I only want one to be shown - the link back to my homepage here. See for example cy:Defnyddiwr:Redrose64 or fr:Utilisateur:Redrose64. In this way, I prevent people at French Wikipedia looking in vain on German Wikipedia, and trying Wiki after Wiki until they reach the right one. --Redrose64 🌹 (talk) 18:26, 3 October 2024 (UTC)[reply]
Oh, okay. It seemed like a bug to me, but I guess I was wrong. SirMemeGod18:28, 3 October 2024 (UTC)[reply]

Why are the buttons glitched out/distorted

[edit]

The delete template (while editing an article), wikitext (while viewing a revision) and edit template (while editing an article) buttons are glitched out and/or distorted. How do I fix this?? Susbush (talk) 15:12, 3 October 2024 (UTC)[reply]

I think this is the same problem as T376226, which is being fixed. Matma Rex talk 18:24, 3 October 2024 (UTC)[reply]
Yes it is Susbush (talk) 18:56, 3 October 2024 (UTC)[reply]

Help Escalating security issue with Webauthn

[edit]

With the help of WMF staff we identified a critical issue with webauthn that is likely locking users out of their accounts. The issue prevents webauthn activated on a device from being used on another device, or between browser sessions. This means users can be activating webauthn , intending to secure their account, and end up losing access to wikipedia. Because relatively few users activate this feature in the short term, the issue may not be getting the attention it deserves. It will also discourage future users from activating webauthn, which is a critical security feature to protect the community.

Please help me find the appropriate contact with WMF technical staff to help get the fix merged. It's a one-line fix from upstream repository so it should be low risk. Tonymetz 💬 16:50, 3 October 2024 (UTC)[reply]

I guess that would be us, the Platform Team. I'll raise it with the team and we'll have a look. Matma Rex talk 19:30, 3 October 2024 (UTC)[reply]
Thanks for the note, webauthn has multiple known issues and is certainly in the "experimental" role. As far as our contributors and readers here at the English Wikipedia go: webauthn shouldn't be used by anyone for anything important. Technical reports in phabricator are of course welcome. — xaosflux Talk 00:09, 5 October 2024 (UTC)[reply]
thanks for the context. On the ticket , Reddy mentioned it was completed by a contractor and hasn't been supported. To whom could I appeal to have it turned off? I believe it's locking people out, so it's a liability. Tonymetz 💬 18:00, 7 October 2024 (UTC)[reply]

"Add A Fact" LLM browser extension

[edit]

After reading [3] and the post and ensuing discussion here, I don't think this browser extension is ready for article talk pace on en.wiki. I'm not exactly sure where to voice a concern about this, so please move this feedback if appropriate. @Chemipanda, Ita140188, and Avatar317: VQuakr (talk) 20:04, 3 October 2024 (UTC)[reply]

@VQuakr Feedback should probably go to meta:Talk:Future_Audiences/Experiment:Add_a_Fact. --Ahecht (TALK
PAGE
)
21:05, 3 October 2024 (UTC)[reply]
That would be fine for feedback to them; I guess here I'm more looking to see if there's agreement this shouldn't be used on en.wiki yet. VQuakr (talk) 21:20, 3 October 2024 (UTC)[reply]
@VQuakr For reference, here is a list of all the edits made using this tool: https://hashtags.wmcloud.org/?query=addafact&project=en.wikipedia.org&startdate=&enddate=&search_type=or&user= 86.23.109.101 (talk) 21:59, 3 October 2024 (UTC)[reply]
That is a helpful link, thanks!! I glanced at ~10 random ones, and they all looked fine; They were a sentence directly copied from the source with the text listed in the quote parameter for the cite. Maybe Chemipanda didn't use it properly (highlighted the title) or is running an outdated browser version? Editors should at least look at their generated posts to see whether they are normal/valid/coherent and revert them if not; this tool is still experimental.
If this were to work as promised, I see this as more helpful than people simply posting new sources in the Talk pages. (which is always helpful). ---Avatar317(talk) 22:39, 3 October 2024 (UTC)[reply]
@Avatar317 Yes, Looking through the edits my impression is that most of them are fine.
According to the page on meta the person using the tool has to select which part of the source to use, so the "adding the title of a paper rather than it's content" is user error, rather than an issue with the tool. There is still the issue of using the wikipedia page in the citation template that needs to be investigated though. 86.23.109.101 (talk) 11:54, 4 October 2024 (UTC)[reply]
I asked a developer and they suggested that the original error was likely due to the user switching browser-tabs while the extension is scanning the page. Quiddity (WMF) (talk) 00:38, 8 October 2024 (UTC)[reply]
Thanks everyone for the insight and especially @Quiddity (WMF): for the follow up! VQuakr (talk) 04:44, 8 October 2024 (UTC)[reply]
[edit]

Not sure if here or the Help desk is the right place... Anyway, I've two questions, please:

  1. Is there a way (e.g., a tool) to extract diffs without going through the page history?
  2. When I click on the timestamp of a signature, I get a comment-specific link (e.g., [4]). I couldn't find any help pages about this kind of link. Is there a reason why we provide diffs instead of these comment-specific links, which seem much easier to obtain?

Thanks, Gitz (talk) (contribs) 09:56, 4 October 2024 (UTC)[reply]

For your question 2, they are described at mw:Help:DiscussionTools § Talk pages permalinking. jlwoodwa (talk) 16:31, 4 October 2024 (UTC)[reply]
The comment links are a fairly new feature, only enabled on English Wikipedia in June (T365974). I suspect many editors haven't warmed up to them yet. Diffs may also be used in some cases if you want to avoid ambiguity as to who wrote what, since anyone can technically edit anything on any page. Comment links are much more convenient for reading or commenting in the linked discussion though. Matma Rex talk 17:19, 4 October 2024 (UTC)[reply]
By extract diffs you mean? Izno (talk) 18:28, 4 October 2024 (UTC)[reply]
Thank you all for your helpful responses - I wasn't aware of that Help page. By "extract diffs" I meant accessing or generating the diffs directly from the talk page, without manually navigating through the page history. When I hover over the timestamp, I see a series of options ("actions", "popups") but none for getting the diff, so I was wondering if there's a tool or shortcut to generate one. Gitz (talk) (contribs) 20:02, 4 October 2024 (UTC)[reply]
No, I don't think there's a tool like that. Izno (talk) 20:46, 4 October 2024 (UTC)[reply]
Diffs between what, from what talk page? Please provide an example. Nardog (talk) 22:56, 4 October 2024 (UTC)[reply]
I assume Gitz6666 means the diff in which that comment was written. jlwoodwa (talk) 23:00, 4 October 2024 (UTC)[reply]
Yes, that's what I meant - a direct way for obtaining this [5] from this [6] without going through the page history. Gitz (talk) (contribs) 23:16, 4 October 2024 (UTC)[reply]
Gitz6666, I think User:Alexander Davronov/HistoryHelper fits that bill. — Qwerfjkltalk 16:33, 5 October 2024 (UTC)[reply]
Thank you. That tool is not exactly what I was looking for (you still need to go on the page history) but is amazing: very helpful indeed!
There's a minor issue though. It works perfectly for creating "special:diff/ links". Using it, I created this:
But if I try to create a {{diff2}}, I get this:
which is {{diff|prev|1249444013|4 ott 2024, 23:16}} and doesn't work. I have to turn it into a {{diff2}} by adding a "2" and removing "prev", to get this:
which is {{diff2|1249444013|4 ott 2024, 23:16}} and works.
I ping @Alexander Davronov: with many thanks for the tool. Gitz (talk) (contribs) 18:34, 5 October 2024 (UTC)[reply]
If you use a browser that supports Chrome or Firefox extensions, you can try the mw:Who Wrote That? browser extension. isaacl (talk) 23:28, 4 October 2024 (UTC)[reply]
"WWT only works on article pages (not talk, user, or other pages)." Nardog (talk) 23:30, 4 October 2024 (UTC)[reply]
Sorry; for some reason, the mention of signatures didn't make me think about non-article pages. isaacl (talk) 23:34, 4 October 2024 (UTC)[reply]
There is the "WikiBlame" tool (which is linked on history pages under "External tools: Find addition/removal"): https://wikipedia.ramselehof.de/wikiblame.php?lang=en. For example, we can find the diff of your original post in this topic this way: [7][8]. Matma Rex talk 19:56, 5 October 2024 (UTC)[reply]
By the way, the database behind the comment links includes the diff numbers of the revision that added the comment (see docs here), although only for comments that were posted since the comment links were enabled – we weren't able to process all historical revisions, it would have taken forever [I worked on this feature with the Editing team about a year ago]. So you could run a SQL query like this to look it up:
select min(itr_revision_id)  
from discussiontools_item_revisions  
left join discussiontools_item_ids on itr_itemid_id=itid_id  
where itid_itemid='c-Gitz6666-20241004095600-Diffs_and_comment-specific_links' 
and itr_transcludedfrom is null;
+----------------------+
| min(itr_revision_id) |
+----------------------+
|           1249323141 |
+----------------------+
…but we never got around to building a user interface for that (Special:FindComment only shows the latest revisions of pages containing the comment, not the oldest), and we also apparently never got around to setting up replication of those tables to the public replicas (although they could be replicated, as noted in T303295#7850298), so you can't even build a Toolforge tool to do it right now. These things could be done with a bit of effort, though… Matma Rex talk 20:30, 5 October 2024 (UTC)[reply]

I dislike the visual changes to Mobile Wikipedia

[edit]

I havent used the community pool before so Im sorry if this isnt in the right village. mobile wikipedia starting today as for some reason started auto directing me to en.m.wikipedia.org instead of the regular en.wikipedia.org. even if i directly remove the ".m" or "m.", it will just autodirect to it again. I really hate it, and find it unbearable to use and love the regular english language wikipedia much more. I dont know what is causing this problem. I havent seen anyone discussing this on either the wikipedia subreddit (where usually any updates are discussed) or on Wikipedia:News. I greatly appreciate any help with this, thank you! 92.236.211.53 (talk) 13:55, 4 October 2024 (UTC)[reply]

Use the "Desktop" link at the bottom of mobile pages to request the desktop version. PrimeHunter (talk) 14:00, 4 October 2024 (UTC)[reply]
Thank you for your quick response! I already tried this and it unfortunately results in it providing the literal desktop version of the website, resulting in large amounts of negative space and awkward text placement next to images due to website trying to work for the horizontal mobile. the site worked perfectly for mobile prior. is this happening on your phone too? 92.236.211.53 (talk) 14:07, 4 October 2024 (UTC)[reply]
im typing from desktop as i also learned today that my phone's ip (this same ip) was caught up in a rangeblock to block a specific user(but is now resolved?). i thought just now that this might be whats causing this but i just made account on mobile and it still autodirects to en.m.wikipedia. i have no idea what to do 92.236.211.53 (talk) 14:28, 4 October 2024 (UTC)[reply]
Device name:Pixel 6a
Model:Pixel 6a
Android version:12
I wish this information perhaps helps in finding out how to reverse this. I sent this from my mobile. 92.236.211.53 (talk) 16:48, 4 October 2024 (UTC)[reply]
The behavior you're experiencing is how it has always worked. The "workaround" Primehunter provided is working how it has always worked. There isn't a way to "fix it". The closest thing you can do is have an account, change the account's skin preference, and then use the "use desktop" link when you are logged in and end up on the mobile website. Perhaps this is sufficient for you. Izno (talk) 18:31, 4 October 2024 (UTC)[reply]
I went back through screenshots I took and saw that you and Primehunter were right, it has always been "en.m.wikipedia". I think there's been an update to mobile Wikipedia's base, light colour scheme that caused the add-on I was using, darkreader to render it differently.
I do notice that the text on tables is larger, and colours are in my opinion not working well together either in the official dark mode or using my add-on on light mode.
Current, disliked Wikipedia (lightmode+darkreader) from today: https://imgur.com/a/wnNflgF
Correct Wikipedia, just darkmode with no add-ons, also today:https://imgur.com/a/4xdBsow
Previous mobile Wikipedia colour scheme (lightmode+darkreader), from 28th of April: https://imgur.com/a/up24a8G
Is there anyway to go back to how it was previously because I really do prefer how it was literally just yesterday? I'm sincerely sorry for the misunderstandings 92.236.211.53 (talk) 19:33, 4 October 2024 (UTC)[reply]
What specifically do you dislike about the "current" version? Izno (talk) 00:09, 5 October 2024 (UTC)[reply]
There is a higher contrast between the letters and the dark background, the purple that lists clicked-on links is a lighter purple so you have to strain your eyes more to discern it, the text on tables is larger than it needs to be while the text on the rest of the articles is currently still at their previous very good and readable size (shown in the imgur comparison linked above), and I dont get how that happened.
I dont know how else to describe it, but it looks like there is a white or blue filter over the articles that makes my eyes hurt. I can make another imgur comparison if that would help explain what im reffering to (just two image links this time tho). 92.236.211.53 (talk) 15:35, 6 October 2024 (UTC)[reply]
If you create an account or add ?useskin=timeless, then the desktop version is more mobile friendly a bit. Gryllida (talk, e-mail) 07:29, 7 October 2024 (UTC)[reply]

Is AutoEd safe

[edit]

I installed the script and all of its modules, is it safe or not? Electrou (formerly Susbush) (talk) 19:00, 4 October 2024 (UTC)[reply]

You're responsible equally for all the edits made with automated tools, if that's what you're asking. You still have to check to make sure your edits are correct and not disruptive. Remsense ‥  19:04, 4 October 2024 (UTC)[reply]
The original poster is probably referring to the message that begins "Code that you insert on this page could contain malicious content capable of compromising your account ..." at MediaWiki:Userjsdangerous. To answer the original question, yes, it is safe. Graham87 (talk) 02:05, 5 October 2024 (UTC)[reply]
You can never be sure of that about user scripts (hence the warning). AutoEd and its modules are in the Wikipedia namespace and protected, which means they can be compromised if any admin's account is compromised. Nardog (talk) 02:12, 5 October 2024 (UTC)[reply]
Yes, but the message @Graham87 linked to ends, If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump., which is what directed the OP here.
It's kind of pointless to do that if the answer is always going to be, "Weeeelll... you can never be completely certain..." — that's not helpful. The user was already warned, and while it's true that you never can be completely certain, the AutoEd code is currently safe. And since it's used by many Wikipedians, it will screw over a much larger portion of the community than just @Electrou in the unlikely event that it becomes unsafe, so it's probably not worth personally fretting over. FeRDNYC (talk) 17:35, 8 October 2024 (UTC)[reply]
Most scripts are either in the MediaWiki namespace where js pages can only be edited by interface administrators, or in userspace where they can only be edited by the user and interface administrators. AutoEd is in the Wikipedia namespace for some reason. The pages are fully protected but all administrators can edit them so it's less protected than most scripts. There are currently 847 administrators but only 10 interface administrators and it's a more trusted position. Apart from the risk of malice, ordinary administrators may also know less about JavaScript and security (including securing their account), and accidentally do something unsafe. PrimeHunter (talk) 20:46, 8 October 2024 (UTC)[reply]

Wikisource & HTTP 429

[edit]

There is an issue with Wikisource and error 429 which could use more technical eyes. Please see this commons discussion and this WS discussion. Thanks for any help or advice you can give. Cremastra (talk) 23:44, 4 October 2024 (UTC)[reply]

Production system errors should be reported via this phabricator form. Has a ticket been opened there yet? — xaosflux Talk 00:00, 5 October 2024 (UTC)[reply]
I don't believe so. A WMF employee said they would file a phabricator task, so we should probably wait so a duplicate doesn't get created by accident. Cremastra (talk) 01:20, 5 October 2024 (UTC)[reply]

How do title bar colors get into an infobox?

[edit]

I'm trying to track down where to flag inaccessible colors in an infobox.

For example, the page Oakland Coliseum station has a station infobox in which titles have insufficient contrast with their background. But if I look at the infobox code on that page, I only find the parameter:

style = BART

and no color coding. So apparently the BART style is stored somewhere else. And so it doesn't make sense for me to flag Oakland Coliseum station but rather wherever the BART style is stored. But I have no idea how to track that down. In fact, if I read the {{Infobox station#External_style_template}} documentation, it says that the above code should correspond to an existing {{BART style}} template. But that template doesn't seem to exist.

How do I find the problematic code? Thisisnotatest (talk) 01:34, 5 October 2024 (UTC)[reply]

Module:Adjacent stations/BART? Nardog (talk) 02:16, 5 October 2024 (UTC)[reply]
Thank you! That was worth checking. Unfortunately, that doesn't seem to be it. Of course, if it was it, the documentation for {{Infobox station#External_style_template}} would need to be updated to allow for other sources than {{BART style}}.
But it isn't. Module:Adjacent stations/BART is using a light blue of #00aeef while the light blue in the Oakland Coliseum station infobox is a light blue of #0099d8.
So still looking. Thisisnotatest (talk) 02:38, 5 October 2024 (UTC)[reply]
Oops! Just looked at the source code. That does appear to be it. The documentation for that module doesn't mention the infobox header colors. So the documentation for {{Infobox station#External_style_template}} does need to be updated. I'll post on the talk page of both items, as I'm not Lua-savvy nor infobox savvy. Anyway, major thanks! Thisisnotatest (talk) 02:43, 5 October 2024 (UTC)[reply]
For some years now, the maintainers of Template:Infobox station have had a drive away from separate templates for icons, routes, stops, styles, etc. to modules holding all information for a system: Template:BART style (and some others) was deleted soon after the creation of Module:Adjacent stations/BART more than five years ago, see Wikipedia:Templates for discussion/Log/2019 July 16#BART s-line templates. Unfortunately, if you don't know Lua, these modules can be difficult to understand let alone maintain.
I see that you have posted to Module talk:Adjacent stations/BART, but that page has very few watchers (5, to be exact); fortunately, Mackensen (talk · contribs) is among them. If you have other similar modules with problems, Template talk:Adjacent stations (which is redirected from Module talk:Adjacent stations) would be a much better place, as it has 32 watchers. --Redrose64 🌹 (talk) 10:05, 5 October 2024 (UTC)[reply]

Template Data report for talk page usage

[edit]

Adding Template Data to a template makes a parameter usage report available. Here's one for {{cite archive}}: [9] Is there a way to use this on templates that are meant for talk pages? For example, {{Archive}} is used on hundreds of thousands of pages (in the talk namespaces), but its report only shows a couple of uses in the Portal namespace: [10] Rjjiii (talk) 03:21, 5 October 2024 (UTC)[reply]

Help with string replace in Templates

[edit]

Hi. Is there somewhere I can ask about using string replacement features in templates? I've been trying things like

strip numbers: {{#invoke:string|replace|source={{{exotic}}}|pattern=%-%d%,|replace=HHH}}

And I've only been able to make very simple substitutions. I'm familiar with regex etc. I must be missing something fundamental. Thanks. Johnjbarton (talk) 20:22, 5 October 2024 (UTC)[reply]

@Johnjbarton: You need |plain=false if you use regex. See Module:String#replace (gsub). PrimeHunter (talk) 20:31, 5 October 2024 (UTC)[reply]
@PrimeHunter Thanks!
However something else is very weird. Here I copied some numbers from the 'edit' view in a wiki page:
strip literals copied: {{#invoke:string|replace|source=−4, −2, −1, 0, +1|pattern=%-%d%,|replace=HHH|plain=false}}
gives
strip literals copied: −4, −2, −1, 0, +1
But if I type the characters in:
strip literals typed: {{#invoke:string|replace|source=-4, -2, -1, 0, +1|pattern=%-%d%,|replace=HHH|plain=false}}
I get
strip literals typed: HHH HHH HHH 0, +1
These look the same to me, but somehow no match? I think this is related to my failure when using a parameter for the source. Johnjbarton (talk) 21:58, 5 October 2024 (UTC)[reply]
@Johnjbarton: The string you copied has minus signs in accordance with Wikipedia:Manual of Style/Mathematics#Minus sign. You typed hyphens which is a different character. Some browsers match on both with a browser page search like Ctrl+f but Lua does not. PrimeHunter (talk) 22:11, 5 October 2024 (UTC)[reply]
Thank you. That explains where my morning went ;-) Johnjbarton (talk) 22:14, 5 October 2024 (UTC)[reply]
And one other issue I accidently discovered: AFAICT you can't match on <ref>...</ref> because the ref tag is somehow rendered to a <span>...</span> before the match. Johnjbarton (talk) 22:27, 5 October 2024 (UTC)[reply]
Refs get mw:Strip markers and interact oddly with some features. Consider for example {{#invoke:string|replace|source=<ref>U</ref>|pattern=U|replace=V}} which produces: '"`VNIQ--ref-0000003D-QINV`"'. Huh? The replacement doesn't work inside <ref>...</ref> but it does work on the strip marker where it changes UNIQ...QINU to VNIQ...QINV. This exposes the now incorrect strip marker. The reference still works in spite of this but there is no link to it. PrimeHunter (talk) 23:47, 5 October 2024 (UTC)[reply]
Yes, I stumbled into that one too ;-) I found Template:Strip tags for giving the text other than the refs so I was trying to find a way to get the inverse function, just the content not the refs. I succeeded in part but my solution is not robust, too many ways to fail. I think now I will regroup and plan to edit the input data into a form that is easier to format with templates. Johnjbarton (talk) 00:16, 6 October 2024 (UTC)[reply]
@PrimeHunter Can #invoke:string|replace be cascaded, that is input as source= for another #invoke:string|replace? Seems like that would just work, but my out call does not match, just passes through. My attempt: User:Johnjbarton/sandbox/Infobox element/symbol-to-oxidation-state-entry Johnjbarton (talk) 21:53, 6 October 2024 (UTC)[reply]
@Johnjbarton: It works but you were missing a pipe.[11] There is also {{MultiReplace}}. PrimeHunter (talk) 22:19, 6 October 2024 (UTC)[reply]
Lua patterns are not regex, they are closer to C string format patterns. Notably, no logical OR ((A|BC)) and no lookaheads/behinds. Izno (talk) 21:31, 5 October 2024 (UTC)[reply]

References

  1. ^ U

Problem to sort data

[edit]

There is problem in this list (section "Minimum wages by country" and "Minimum wages by country (other countries)") to sort data by "Net (EUR)" and "Net (PPP)". What to do? Eurohunter (talk) 15:07, 6 October 2024 (UTC)[reply]

What is the problem? It seems to work for me. – Ammarpad (talk) 17:07, 6 October 2024 (UTC)[reply]
@Eurohunter you have described everything BUT the 'problem'. Never assume that others are seeing or experiencing the same thing as you, and make full and extensive descriptions of the problem that you are encountering. —TheDJ (talkcontribs) 19:04, 6 October 2024 (UTC)[reply]
@@Ammarpad: @TheDJ: Sort it by lowest or highest value, a few times. Eurohunter (talk) 20:35, 6 October 2024 (UTC)[reply]
@Eurohunter: I did and see no issue. WHAT IS THE PROBLEM? It's hard to help when you refuse to reveal what you think is wrong. PrimeHunter (talk) 21:26, 6 October 2024 (UTC)[reply]
The third click on EUR sort buttons takes you back to the initial sorting, which is a sorting by country name. It is not a bug, it is a feature. Uwappa (talk) 09:35, 7 October 2024 (UTC)[reply]
@TheDJ: @PrimeHunter: @Uwappa: Looks like I was wrong, but just noticed it's impossible to sort by "Gross (EUR)". Eurohunter (talk) 16:55, 7 October 2024 (UTC)[reply]
@Eurohunter: The "Gross (EUR)" column has an image before the number. You can for example use data-sort-value at Help:Sortable tables#Specifying a sort key for a cell. PrimeHunter (talk) 17:08, 7 October 2024 (UTC)[reply]
The column header has the attribute data-sort-type="number" but the data cells in that column all begin with either {{steady}}, {{increase}} or {{decrease}}, none of which are numeric. --Redrose64 🌹 (talk) 18:21, 7 October 2024 (UTC)[reply]

youtu.be blacklist

[edit]

When I share a youtube video with a timestamp I get a link like this:

https://youtu.be/Zl8BIUx8QW0?feature=shared&t=1

but when I try to post that on wikipedia it says the link is on a spam blacklist. I can't find it on meta:Spam blacklist or on MediaWiki:Spam-blacklist.

And it wouldn't even make sense to block it anyway because I can change the link to:

https://www.youtube.com/watch?v=Zl8BIUx8QW0#t=1

and suddenly it is allowed. Polygnotus (talk) 21:24, 6 October 2024 (UTC)[reply]

Shorteners are categorically rejected. This one is rejected at meta:Spam blacklist \byoutu\.be\b. Izno (talk) 21:29, 6 October 2024 (UTC)[reply]
Thank you. The spam blacklist is intended to blacklist spam, and shouldn't be hijacked by people with an irrational hatred for url shorteners. Polygnotus (talk) 21:36, 6 October 2024 (UTC)[reply]
URL shorteners are used to introduce spam, and aren't always particularly stable addresses, and they can lead to hijacked sites, which are much more dangerous than spam. These reasons for banning them are categorically rational, contrary to your hyperbole. No, they will remain banned. Whether specifically youtu.be should have an exception is perhaps a worthy question, but as you said, the expansion is trivial, so just use the full URL instead. Izno (talk) 21:48, 6 October 2024 (UTC)[reply]
Yes. Shirley there Izno reason not to use the full URL. EEng 23:07, 7 October 2024 (UTC)[reply]
@Izno: I know what URL shorteners are. This particular URL shortener cannot be used for malicious purposes because it only redirects to youtube. So it is obviously irrational to block all url shorteners. It is rational to block attack vectors while leaving domain aliases unblocked. This kinda stuff should be decided on a case-by-case basis (e.g. block bit.ly and tinyurl but not youtu.be). I can use the full url, but others do not know how to do that. Polygnotus (talk) 22:00, 6 October 2024 (UTC)[reply]
If someone doesn't know what a URL is or how to copy and paste it, they definitely shouldn't be adding external links to articles. Thebiguglyalien (talk) 06:27, 7 October 2024 (UTC)[reply]
@Thebiguglyalien: If someone says something truly ridiculous, it is often wise to re-read it in its context. Polygnotus (talk) 06:30, 7 October 2024 (UTC)[reply]
URL shorterners are blacklisted for good reasons. They can be used to circumvent blacklisting of their target. MediaWiki:Spam-blacklist blacklists several specific videos at youtube.com, e.g. the entry \byoutube\.com\/watch\?v=W0a6L7hbD7U\b. We don't want spammers to use a youtu.be redirect instead. And there are other problems with URL shorternes, e.g. that they can be shut down and break all links. If you don't think YouTube's owner Google would do such a thing then think again. They are shutting down their URL Shortener goo.gl.[12] PrimeHunter (talk) 21:55, 6 October 2024 (UTC)[reply]
Gotta love https://killedbygoogle.com/ Polygnotus (talk) 22:00, 6 October 2024 (UTC)[reply]
I actually agree that youtu.be shouldn't be blacklisted. The solution to PrimeHunter's concern would be to just blacklist the string W0a6L7hbD7U instead - the blacklist doesn't have to point to the full URL. But despite being a Meta admin and thus having the technical power to action this I don't have the social power to do it myself. * Pppery * it has begun... 02:26, 7 October 2024 (UTC)[reply]
@Pppery: Thanks! The discussion continues at meta:Talk:Spam_blacklist#youtu.be. Another advantage of blocking W0a6L7hbD7U is that it would work for both the youtu.be/%id% and /watch?v=%id% format. Polygnotus (talk) 02:33, 7 October 2024 (UTC)[reply]
The key point here, which was (indirectly) mentioned by the OP, is that https://youtu.be/video_id links are provided by YouTube itself directly from their UI whenever a "Share" link is requested for a video. They are, in a certain sense, even more of a permalink than the actual https://www.youtube.com/watch?v=video_id page they redirect to.
And while it's true Google could terminate support for https://youtu.be/ tomorrow, they could also redesign YouTube tomorrow so that the https://www.youtube.com/watch page is no longer functional, replaced by https://www.youtube.com/view or some other nonsense, which the https://youtu.be/ redirects get updated to point to.
Do I think that will happen? Absolutely not; I just think it's of equal unlikelihood (...ow) that anything will happen to https://youtu.be/, as that would break like a quarter of the entire frickin' internet.
The simple fact is, when requesting links to YouTube videos from YouTube itself, users are provided with https://youtu.be/ links, which IMHO we shouldn't make it unreasonably difficult to make use of.
Especially considering, if a user is viewing a video in the YouTube mobile app (which accounts for a very significant percentage of YouTube traffic, at a level that shames our own mobile app's laughable 2%-3% of monthly pageviews), the short URL is the only URL they can retrieve. The app doesn't expose https://www.youtube.com/watch?v=video_id URLs anywhere. FeRDNYC (talk) 18:03, 8 October 2024 (UTC)[reply]
Linking to invidious instance could be better, it loads faster and does not track the user as much. Gryllida (talk, e-mail) 07:26, 7 October 2024 (UTC)[reply]
See Principle of least astonishment. Polygnotus (talk) 07:28, 7 October 2024 (UTC)[reply]
The two issues appear to be the general issue with url shorteners, and spamming of the shortened url.
Although this is a url shortener it's doesn't have the issues inherent in most shorteners. The only end point is a youtube video, so the usual concerns that it could link to anything do not apply here. Whether you use .com or .be you can't link to anything but a youtube video (correct me if that's wrong).
The spam issue is separate, and blacklisting individual videos is a poor option unless it's in a very particular situation. But the .com version could be spammed as well. I don't know how long ago the spamming and blacklisting were, but maybe unblacklisting as a test would be useful. If the past issues reappear it could be reapplied. I can see reasons why the .be link would be easier to spam, but beans. -- LCU ActivelyDisinterested «@» °∆t° 18:59, 8 October 2024 (UTC)[reply]

Lua to generate information about a page

[edit]

Hello, does lua template have the capability to get information like

  • page contributors
  • last date of edit to page

for a provided page name? If so, please send me an example? Thank you. Gryllida (talk, e-mail) 07:23, 7 October 2024 (UTC)[reply]

@Gryllida: You don't need Lua for the second one, it is available as a variable. If you only need the last contributor, that also is available in the same way. --Redrose64 🌹 (talk) 09:40, 7 October 2024 (UTC)[reply]
Need this info for page and for page talk so I think variable will not work. Need a list of contributors not only last one. I can get this information using js but would prefer to avoid it. if possible. Thanks. Gryllida (talk, e-mail) 14:16, 7 October 2024 (UTC)[reply]
Why do you think that a variable wouldn't work? Consider the article London - we can do this:
  • {{REVISIONTIMESTAMP:London}} → 20241006081446
    {{#time: H:i, j F Y (e)|{{REVISIONTIMESTAMP:London}}}} → 08:14, 6 October 2024 (UTC)
  • {{REVISIONTIMESTAMP:Talk:London}} → 20240908185015
    {{#time: H:i, j F Y (e)|{{REVISIONTIMESTAMP:Talk:London}}}} → 18:50, 8 September 2024 (UTC)
If either London or Talk:London get edited, the above examples will change when this page is next edited or WP:PURGEd. --Redrose64 🌹 (talk) 16:04, 7 October 2024 (UTC)[reply]
This is fabulous Thanks. I will go try to use it in my template now. Just need the nicks of contributors now if possible. Gryllida (talk, e-mail) 22:59, 7 October 2024 (UTC)[reply]
No, Lua (Scribunto) does not have access to page history. One option would be to have a bot periodically build a list of contributors and update a page somewhere that a module could read. Or, have a JavaScript gadget which can use the API. All that is tricky. Johnuniq (talk) 00:41, 8 October 2024 (UTC)[reply]
Js is ok,I can write. I was hoping for Lua. Why not? Can it be implemented for Lua to have such access? Thanks for your insight. 🙂 Gryllida (talk, e-mail) 10:28, 8 October 2024 (UTC)[reply]
Part of the answer to that question is likely something vaguely along the lines of, "just as we expect of all wikipedians, Scribunto is here to create an encyclopedia, and no part of that goal ever requires access to edit history."
(Which... is actually kind of true. There are plenty of behind-the-scenes tasks/goals that could benefit from page history access, but none of them would ever directly affect article content.) While there are plenty of conceivable ways in which it would be useful to have history access (or other functionality) in Scribunto, the focus has primarily been on providing functional equivalents to what's achievable with template coding, but without the template-coding nightmares involved in building any sort of complex logic.
Templates similarly have no access to page history.
Another factor is that the results of Module {{#invoke:}} calls, like template transclusions, are meant to be cacheable. 'Dynamic' code that relies on making an external resource query, meaning it potentially changes each time the module is invoked, is a bad fit with the caching model. Lua results should ideally be fairly static unless a dependency is edited or the code is invoked with different parameters.
Not to say that these things couldn't, potentially, be implemented. They just haven't been, and adding them would be a significant development effort, it's not a matter of flipping a switch or inserting a line of code somewhere. In fact there's a Phabricator tracking bug (T50176) for bugs requesting new Lua functionality — it's a long list. Things like MediaWiki API query access, access to Category lists, Namespace indexes, etc. are already there. It doesn't look like edit history access has ever been directly requested. (But API queries would provide one potential path, since page history info is accessible via the API.)
It's important to note that none of those requests are actively being worked on, though. They're just that: Requests. Unfulfilled requests, with no predicted timeline for completion beyond "...probably never?" FeRDNYC (talk) 21:52, 8 October 2024 (UTC)[reply]

How to delete from talk page

[edit]

How do I delete a section (blank entire section) from my personal user talk page? I used to do it with a script from times before the software upgraded to include new stuff (e.g. subscribe button, 'Latest comment: 22 minutes ago | 1 comment | 1 person in discussion' and the like. Gryllida (talk, e-mail) 07:46, 7 October 2024 (UTC)[reply]

@Gryllida: Edit the section, click anywhere in the edit box, then do: Ctrl+A   ← Backspace   Alt+⇧ Shift+S. You can use Delete instead of ← Backspace if that's easier for you. --Redrose64 🌹 (talk) 09:45, 7 October 2024 (UTC)[reply]
My script used to do it in one click. Gryllida (talk, e-mail) 14:14, 7 October 2024 (UTC)[reply]
Do you mean that you want another archiving script? I use (a fork of) https://en.wikipedia.org/wiki/User:Elli/OneClickArchiver.js Note that it possible to disable that new stuff. Polygnotus (talk) 09:49, 7 October 2024 (UTC)[reply]
Yes I will check it out thanks. Gryllida (talk, e-mail) 14:16, 7 October 2024 (UTC)[reply]
Your script stopped working likely due to mw:Heading HTML changes. Nardog (talk) 14:43, 7 October 2024 (UTC)[reply]

Bug in Template:Infobox musical artist

[edit]

The parameter "associated_acts" doesn't work, see Orelsan. --BigBullfrog (talk) 08:19, 7 October 2024 (UTC)[reply]

@BigBullfrog: Well, no, because it's deprecated to the point of removal. See Template talk:Infobox musical artist/Archive 16#Associated acts confusion and Category:Pages using infobox musical artist with associated acts. --Redrose64 🌹 (talk) 09:51, 7 October 2024 (UTC)[reply]
Oh I see, thanks. --BigBullfrog (talk) 01:09, 8 October 2024 (UTC)[reply]

Table

[edit]

How to make this table look like this one? I don't see any parameters which could be used. Eurohunter (talk) 20:52, 7 October 2024 (UTC)[reply]

What do you mean "look like"? They look roughly the same to me, except for some styling applied by |namestyle=, |headingstyle=, |class=, and similar. – Jonesey95 (talk) 21:24, 7 October 2024 (UTC)[reply]
I'm gonna dissent from @Jonesey95's claim as those boxes look pretty significantly different to me, but I agree it's mostly a question of styling, all of which is done by parameters that most assuredly are there and being used ­— most of what's involved in making Template:Politics of Yemen look more like Template:Politics of Uzbekistan would involve removing the ugly style nightmare that's been imposed on the former. Places I'd start:
  • Lose the border: 1px double #8C959A from all of the style parameters where it's used (titlestyle, headingstyle, and listtitlestyle), because that just looks like trash.
  • Just remove |style=border 4px double var(--background-color-inverted, #101418); completely. (What is this obsession with double-lined borders?)
  • Use {{Politics sidebar title}} to set the |title= parameter, rather than hardcoding separate |title=, |image=, |namestyle=, |titlestyle=, etc. Specifically, you'd probably want this:
    |title={{Politics sidebar title|country=Yemen|image=Emblem of Yemen (2).svg|size=125px|title=Yemen}}
    
    replacing not only |title= itself but also those other three parameters.
  • Consider getting rid of the |headingstyle= and |listtitlestyle= entirely, as well. Beyond the border styling, all they do is set specific (and ugly) color parameters that ruin the look of the sidebar because content boxes of unequal dimensions are revealed. That makes for a very "ransom-note" kind of effect where different-sized yellow rectangles and red rectangles are slapped all over the place.
  • Finally, if you don't want the contents of each expandable heading to be presented as just a wrapped horizontal line of text, remove hlist from the |bodyclass= parameter, as that's what makes them format that way.
    (If you do that, you might consider using the {{hlist}} template to create horizontal lists out of some of the links in specific lists, like Template:Politics of Uzbekistan does in the |list6= contents.)
FeRDNYC (talk) 22:34, 8 October 2024 (UTC)[reply]

Global.css not affecting mobile

[edit]

My global.css appears to not be working on mobile web (Firefox Nightly on Android) all of a sudden - the changes just aren't applied. It works fine on desktop. Is this a known issue? Suntooooth, it/he (talk/contribs) 21:57, 7 October 2024 (UTC)[reply]

Suntooooth, could you please test in non-nightly version of Firefox for Android? —⁠andrybak (talk) 09:01, 8 October 2024 (UTC)[reply]
Just tried it, still not working. Suntooooth, it/he (talk/contribs) 13:30, 8 October 2024 (UTC)[reply]
Something that may be related - there are also some icons in the interface that aren't showing up on mobile (Firefox Nightly and Firefox). The two I've noticed are the "watch" icon on pages I'm watching, and the red alert circle that displays in the top bar if there's notifications. Suntooooth, it/he (talk/contribs) 13:43, 8 October 2024 (UTC)[reply]
The icon issue is being discussed at Wikipedia:Village pump (technical)#Watchlist icon issue on Mobile. See also phab:T376359, phab:T376414. —⁠andrybak (talk) 13:59, 8 October 2024 (UTC)[reply]
Got it, thanks! :] Suntooooth, it/he (talk/contribs) 14:07, 8 October 2024 (UTC)[reply]

Tech News: 2024-41

[edit]

MediaWiki message delivery 23:38, 7 October 2024 (UTC)[reply]

Refill down

[edit]

This is not a new issue (see previous discussions here and here for example), and I don't frequent the technical pump often, but the extremely valuable Refill tool has been non-functional for months (years?). Any updates? And, if it's broken/abandoned for good, is there a similar tool that can quickly convert bare URLs into formatted citations, and/or combine duplicate citations? Furthermore, is there a clear list of handy editing tools somewhere on Wikipedia? I've been a regular editor for well over a decade, so if there is one, I've overlooked or forgotten about it. There are a lot of problems on Wikipedia: prioritizing tools, and making them easily visible to editors who don't have a computer science degree, should be a top priority. Cheers, --Animalparty! (talk) 00:29, 8 October 2024 (UTC)[reply]

https://refill.toolforge.org/ng for some reason. – Muboshgu (talk) 00:39, 8 October 2024 (UTC)[reply]
I use reFill2 and something called RefRenamer but I don't know the link. Johnjbarton (talk) 00:42, 8 October 2024 (UTC)[reply]
User:Nardog/RefRenamer? Polygnotus (talk) 01:58, 8 October 2024 (UTC)[reply]

how to add geojson map to Infobox protected area

[edit]

I'm trying to add https://commons.wikimedia.org/wiki/Data:Coconino_National_Forest.map to Coconino National Forest but it is unclear to me how to do so. I tried:

| image_map       = {{maplink-road|from=Coconino National Forest.map}}

But it's not showing up. I also tried to delete the old `map` entry and then adding this:

| map       = {{maplink-road|from=Coconino National Forest.map}}

But that got me this error:

Lua error in Module:Location_map at line 526: "?'\"`UNIQ--mapframe-0000000E-QINU`\"'?" is not a valid name for a location map definition.

Any ideas? TerraFrost (talk) 10:35, 8 October 2024 (UTC)[reply]

I previously struggled with a maplink situation where the answer was to wait a few days for Kartographer to sort itself out. CMD (talk) 12:32, 8 October 2024 (UTC)[reply]
The template's documentation suggests using embedded=. The map probably still needs a caption, but it's in the article. – Jonesey95 (talk) 14:31, 8 October 2024 (UTC)[reply]

Sticky table headers placement issue for short/nested tables

[edit]

It looks like someone tweaked the CSS for the sticky table headers — which can be enabled with the fourth checkbox at Special:Preferences#mw-htmlform-gadget-section-test — so that (if your browser also satisfies a @media screen and (min-width: 1000px) media query) it applies a top: 3.125rem offset to table headers when one is stickied, to prevent the sticky header from either covering or sliding under the also-sticky TOC button.

Nice idea, in theory. Problem is, on pages containing nested and/or short tables that don't exceed the height of the screen, the stickiness can kick in at unexpected times, particularly when there are multiple tables. And when that happens, all of the tables' headers jump down a distance of 3.125rem, potentially covering their first data row.

I first noticed this at Module:Sports results, in the documentation. The "What it looks like" areas of those docs all contain short tables. If you have the sticky headers gadget enabled, then no matter where you scroll on that page, each table's header row will be shoved down to cover the first data row below it.

That's a problem, as it obscures content, and the only way to make it visible is to defeat the CSS rule applying top: 3.125rem. FeRDNYC (talk) 16:16, 8 October 2024 (UTC)[reply]

Actually, it looks like this only affects nested tables, and it may be sufficient to augment the existing CSS rule:
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header > thead {
    top: 3.125rem;
  }
}
with a second one overriding the offset in nested tables:
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .jquery-tablesorter > thead {
    top: 0;
  }
}
FeRDNYC (talk) 16:57, 8 October 2024 (UTC)[reply]
...Smaller issue, the nested table headings then end up passing on top of the sticky outer table headers when they cross, instead of underneath them. Looks like some z-index tweaking might also be needed. FeRDNYC (talk) 17:01, 8 October 2024 (UTC)[reply]
Ohh, now I see. The offset isn't to avoid the floating TOC button, but rather the full-width version of the .vector-sticky-header. But the weird thing is, that CSS doesn't kick in until @media screen and (min-width: 1120px), so there's this weird 120px limbo range of browser widths where the table headings are ducking under nothing at all. FeRDNYC (talk) 22:53, 8 October 2024 (UTC)[reply]

Database error, write duration exceeded

[edit]

Just got the following error message dropping three See-alsos from a Draft, in this edit:

Database error
To avoid creating high replication lag, this transaction was aborted because the write duration (5.3958411216736) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.

[bf82d77e-9cdf-4b96-a5b2-5ac9cab8969a] 2024-10-03 15:00:40: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

The edit seems to have gone through fine, despite the message. Could this happen if I inadvertently hit Publish twice or something? I don't have any recollection of doing so, and I really don't know what happened. Everything is fine on my end, I don't need any action, just reporting this in case it's a first sign of something going on that needs to be watched. Mathglot (talk) 15:11, 3 October 2024 (UTC)[reply]

*I unarchived this to reply*. @Mathglot: Sorry I didn't see this earlier, but your description reminded me of a recurring (possible) bug affecting the abusefilter - I checked and it does seem like your edit is related: your edit triggered the monitoring filter 9 times separately from the edit.
I'm unsure how active @Suffusion of Yellow is, the testing filter ("possible abusefilter bug") was added to help debug things from Wikipedia:Edit_filter_noticeboard/Archive_12#Filter_1253:_False_positive_ratio, where @ToBeFree created phab:T348237, about it.
I'm just noting this here, and pinging, in case either this Database error helps with the phab-reported abuse filter problem (or the other way around). – 2804:F14:80E1:2001:2DF4:42B2:8C4D:C416 (talk) 18:22, 8 October 2024 (UTC)[reply]
Thanks for the ping and Mathglot for the report – I have now added this as a comment to the year-old task. ~ ToBeFree (talk) 19:44, 8 October 2024 (UTC)[reply]

Keep getting logged out

[edit]

Over the past few weeks I've been occasionally getting logged out unexpectedly, despite ticking the "remember me" option every time. Most recently it's happened twice in the past ~24 hours. It always happens when I've been idle for a while, but only on the order of hours not days. I'm not aware that I've changed any of my settings recently. Thryduulf (talk) 20:15, 8 October 2024 (UTC)[reply]

Me too. I believe there is a phab ticket covering this issue. Let me go find it real quick NightWolf1223 <Howl at meMy hunts> 20:55, 8 October 2024 (UTC)[reply]
I've had the same issue for a week or so, I just rather lazily assumed it would get fixed at some point. -- LCU ActivelyDisinterested «@» °∆t° 21:08, 8 October 2024 (UTC)[reply]