Wikipedia:Village pump (technical) - Wikipedia

When logged out, in dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 15:47, 5 September 2024 (UTC)Reply

See the notes and linked pages from when you recently asked about this: Wikipedia:Village_pump_(technical)/Archive_214#Dark_Mode_Text. — xaosflux ^Talk 15:56, 5 September 2024 (UTC)Reply

Thanks, I assume that we will have to wait our turn.

The issue is fixed when I am actually LOGGED IN, but not fixed when I am logged OUT. --Jax 0677 (talk) 16:11, 5 September 2024 (UTC)Reply

I made this edit yesterday to improve display of self links in navboxes. I will try to fix this fully today since this specific navbox keeps coming up. Izno (talk) 16:10, 5 September 2024 (UTC)Reply

This should be fixed for this template. Izno (talk) 17:37, 5 September 2024 (UTC)Reply

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:

• Template:Editnotice load (would need to be replaced with {{#invoke:editnotice load|main}})
• Template:Editnotice load/notext (would need to redirect to Template:Editnotice load, or should call {{editnotice load}} but with the parameter "notext=yes")
• Template:Editnotice/notice (would need to be updated to match that on testwiki)
• MediaWiki:Noarticletext-nopermission (should be updated with the following addendum: {{#invoke:editnotice load|protectionEditnotice}})
• MediaWiki:Protectedpagetext (would need to be updated to match that on testwiki)
• MediaWiki:Cascadeprotected (would need to be updated to match that on testwiki)
• Template:Editnotices/Group/Template:Editnotices (would need to be updated to match that on testwiki)
• MediaWiki:Titleblacklist-custom-editnotice (would need to be updated to match that on testwiki)

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}}

• Template:Editnotices/Category/Living people
• Template:Editnotices/Category/Possibly living people

{{Disambig editintro}}

• Template:Editnotices/Category/Disambiguation pages

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 encountered a powerful autodoc tool on Fandom Dev Wiki called Docbunto, and I have been able to get some changes to make it work on Test Wikipedia. I think it would be very great to have an autodoc tool like Docbunto on Wikipedia to help speed up the process of writing module documentation. But the key feature I like is the ability to transclude templates and similar on Lua pages.

I don't think it is ready for English Wikipedia yet but maybe with a few changes it can be very feature rich and ready. Yeah we are not exactly a code repository, but we do have thousands of modules used across articles that would be helpful to have auto documentation for. Awesome Aasim 18:21, 17 September 2024 (UTC)Reply

Wiktionary uses something similar. See wikt:Module:module documentation.
But the key feature I like is the ability to transclude templates and similar on Lua pages. As for this, we can already do this on this wiki: Module:Module wikitext. – SD0001 (talk) 20:15, 17 September 2024 (UTC)Reply

Another improvement we can do over wiktionary is take advantage of line numbers now being linkable. Ideally, the generated docs of exported functions should include links to their source code definitions. – SD0001 (talk) 20:18, 17 September 2024 (UTC)Reply

As for this, we can already do this on this wiki: Module:Module wikitext. That is very bodgy, and it doesn't entirely make sense to me how this works or why this should work. But then, an autodoc module rendering module comments is also very bodgy, although less bodgy because reading out comments to parse from the module is less likely to break than reading out variables from the documentation module after setting them in "addText". Module comments should be taken advantage of in the parser. I did open a task (and submit my first patch to MediaWiki to complete it) for having MediaWiki only parse the contents of CSS and JS comments, see phab:T373834 (and kindly do please send more feedback on how I can improve that patch!) Awesome Aasim 00:21, 18 September 2024 (UTC)Reply

We considered generating documentation from LuaDoc when creating Scribunto, but we decided not to for the same reasons most documentation pages here are on /doc subpages instead of being inline in the template page: inlined docs can't be protected separately from the module/template and any edit to inlined docs means any pages using the module/template have to be reparsed. Anomie⚔ 23:50, 17 September 2024 (UTC)Reply

I'd figure. I think of this inline doc as a good starting point for most Lua modules but ultimately there should be additional documentation that goes beyond the default functions and describes what the module exactly does. Awesome Aasim 23:53, 17 September 2024 (UTC)Reply

Yeah, being able to edit documentation without going through edit requests would be nice, even though so would be autogenerating doc sections for functions. Nardog (talk) 01:20, 18 September 2024 (UTC)Reply

Automated cat herding is not going to work at Wikipedia. Imagine forcing every module to have comments in a fixed format with extra gunk to be machine parsable. Johnuniq (talk) 02:27, 18 September 2024 (UTC)Reply

It is really bad practice to not put comments in code. Autodoc obviously won't work if there aren't any properly formatted comments. The goal of autodoc is to document functions and variables and more importantly module exports. Even functions in use by other modules. It never is intended to replace the module documentation page at the top of each; just supplement it. Awesome Aasim 03:05, 18 September 2024 (UTC)Reply

Yes, useful comments are great. What I meant was, it would be very difficult to get independent editors to use a fixed format. Also, I don't think documenting all functions and variables is achievable or even desirable, for example, due to the inevitable drift between hopeful comments and actual code. I do agree that exports should be documented and I once argued strongly that a module (I forget where now) should not have every function exported due to ensuing confusion and maintenance issues. I lost that argument. Johnuniq (talk) 03:34, 18 September 2024 (UTC)Reply

There is a few related stuff I can think of.

Automatically making a list of variables is actually easy. The hard part is getting arguments in loops. See is:Module:Templatedata fyrir skriftu, which can create basic templatedata (containing only a list of variables) with the code {{#invoke:Templatedata fyrir skriftu|main|''name of module with namespace''}}.

There is also an request to WMF at meta:Community_Wishlist/Wishes/Document_ALL_the_modules! about this same subject.

Come to think of it some of doc.wikimedia.org is actually built on similar logic to docbunto. Snævar (talk) 19:08, 19 September 2024 (UTC)Reply

Why not both? If there's comments in code formatted in a certain way, show them in /doc, but also allow overriding or appending to it without having to edit the module directly. Nardog (talk) 03:37, 18 September 2024 (UTC)Reply

+1. I do think having both is useful. We can provide an end user overview at the top of the module documentation page, and a developer's overview in the autodoc. Something similar to how I implemented autodoc on testwiki:Module:Docbunto and testwiki:Module:i18n. There should be some sort of disclaimer that the documentation is auto generated and the contents can be overridden. Awesome Aasim 14:42, 18 September 2024 (UTC)Reply

I did a little bit more work on the module (not really any), and I am wondering if the module can be imported from testwiki to English Wikipedia? We may have to update some of the attribution links to point to Fandom users, but not much else. Awesome Aasim 01:23, 25 September 2024 (UTC)Reply

You are the only contributor on testwiki. Just copy it. Looks like you've modified Module:Documentation on testwiki to make it automatically show the generated docs. It may be more intuitive to not do that and instead have /doc subpages call the autodoc module (the way it's set up on wiktionary), enabling the automatic and manually written docs to co-exist, making it clearer where the autodoc came from, avoiding the weirdness of a [create] button in the documentation header showing up even when the documentation seemingly exists, etc. – SD0001 (talk) 04:13, 25 September 2024 (UTC)Reply

But the first edit at testwiki includes an edit summary with a link to the source. That should be retained. The subsequent edits may as well also be retained in the history here. I'm still dubious about whether automatic documentation can be helpful at Wikipedia but having it here would allow live demos. Johnuniq (talk) 05:37, 25 September 2024 (UTC)Reply

Problem: That module is at testwiki which does not appear as an option at Special:Import. Only test2wiki is available (it was added in February 2013 when Scribunto appeared here). An alternative would be for Awesome Aasim to duplicate the first edit here, with its edit summary, then make another edit to include the current version. Johnuniq (talk) 05:58, 25 September 2024 (UTC)Reply

Yeah and there are other problems that mean it won't be ready for use right away. See testwiki:Module:Documentation's autodoc, for example.

I still managed to get it onto English Wikipedia so that we can all work together to make it robust. I actually see why the original i18n module was deleted, while the one on Fandom and on other Wikimedia projects was not: it was too simple.

I think it will require some sort of consensus to turn this on by default, but at least we have something to start. Awesome Aasim 07:00, 25 September 2024 (UTC)Reply

On screens below width 640px there are two related issues with table captions in Drummully#Statistics on mobile, ie https://en.m.wikipedia.org/wiki/Drummully#Statistics.

• In both tables, the caption only spans the first column.
• In the first table, the caption is below the column headers.

The cause is the user agent's default display ...

caption {
   display: table-caption;

... is overridden by a Minerva stylesheet

@media screen and (min-width: 640px) {
   .content caption {
       display: block

When I comment out that line in my Browser developer settings, both tables look fine.

The CSS file's URL is

here

I dunno where the corresponding source is, or whether this is a Wikipedia or MediaWiki issue, or if there is a defect logged and/or a workaround available. jnestorius^(talk) 16:05, 18 September 2024 (UTC)Reply

The caption being set to display block has always been weird to me; the other display blocks in Minerva make some sense (but I also think I've played around with this before and come to the conclusion that it was necessary?? memory is weird on this point).

skins.minerva.base.styles/content/tables.less is the source. Izno (talk) 16:32, 18 September 2024 (UTC)Reply

Captions should be either display:table-caption; or display:none;. Nothing else is sensible. --Redrose64 🌹 (talk) 19:39, 18 September 2024 (UTC)Reply

TLDR: The issue is the inline style adding display: inline-table which is interfering with Minerva's ability to make the table responsive on a mobile device. Please move this to a TemplateStyle so that it only applies at a suitable breakpoint and does not break the display on mobile.

Longer version: On mobile, since a table doesn't fit in the screen, presenting them to mobile devices becomes tricky. The way we approach this general in MediaWiki sites, it to convert the display property of all table elements to block-based layouts rather than table-based layouts. Applying display block to the table caption, will ensure that it does not require horizontal scrolling to be viewed and will span multiple lines if needed. While this might seem strange is a pretty widely recommended and sensible practice.

The bug here IMO is not the table caption - it's the use of display inline-table. If you load this article on a mobile device, and expand sections you'll see that this introduces horizontal scroll on the page e.g. the table breaks the content of the whole article. e.g. the whole article is not mobile friendly (note the whitespace to right of chrome in this screenshot: https://phabricator.wikimedia.org/F57532981).

Inline styles as always interfere with a lot of the logic we have to optimize content. As with dark mode where use of any kind of color can break dark mode display - using display or width or height properties interfere with the responsive behaviour and I would personally recommend always using mw:TemplateStyles to express these. 🐸 Jdlrobson (talk) 00:07, 24 September 2024 (UTC)Reply

@Jdlrobson: the bug here is also in having caption { display: block } style as well. See ru:Амстердам#Климат on mobile for where it breaks easily. stjn 18:19, 24 September 2024 (UTC)Reply

Thanks. This looks like a bug in the logic for the noresize class not the caption itself (for the reasons I say above).

I've opened phab:T375563 to sort that out. 🐸 Jdlrobson (talk) 21:38, 24 September 2024 (UTC)Reply

Yesterday, I ran the McAfee "Tracker Remover". Normally, that's routine, and nothing odd happens, but I am wondering if my new quirk was triggered by McAfee . Normally I don't sign out when I leave Wikipedia for the day. But as of today, I'm having issues with Firefox asking me to sign in to Wikipedia. I click without password, and it opens anyway. It's just odd that it asked me to do that. If I open on Chrome or Microsoft Edge instead, both take me right into the Wikipedia page I want without asking for a password. Feedback welcome on this, please. — Maile (talk) 20:31, 19 September 2024 (UTC)Reply

I think it is more likely that you are seeing issues of the login system itself. In layman terms, the Wikipedia/WMF login system is not as safe as Firefox would want, which leads to issues (see https://bugzilla.mozilla.org/show_bug.cgi?id=1696095 and phab:T226797 for techical details). General login issues should be better once phab:T348388 is resolved. Snævar (talk) 08:01, 23 September 2024 (UTC)Reply

Thank you for the information. — Maile (talk) 21:13, 23 September 2024 (UTC)Reply

I was asked to investigate a problem with {{convert}} at the Ukrainian Wikipedia. I have edited some pages there and am curious about the effect of a new user (me) editing a pending-changes protected page such as uk:Module:Convert/пісочниця (/sandbox). When I look at that page in a private window where I am not logged in, I can find "pername". I added that in the most recent edit which history shows as "pending review". Also, the pername change to the module is used at uk:User:Johnuniq/convert#pername (it shows dummy text "miPER" and "acrePER" in the output). In other words, an edit to the module which has not been reviewed still has an effect that is visible to all. This is not important—I'm just curious about WP:Pending changes. It appears that PC on a module does not achieve much other than flagging it as needing review? Johnuniq (talk) 02:58, 23 September 2024 (UTC)Reply

I think templates work the way one would expect, I would guess Scribunto content model pages just don't... Maybe @Stjn knows. Izno (talk) 03:12, 23 September 2024 (UTC)Reply

I just tried editing the PC protected page uk:Template:Convert/пісочниця. In a private window I could see the change to the template, and I could see the effect of the change. (I stuffed up my edit summary when I self-reverted—I meant to say that PC had no effect.) Johnuniq (talk) 03:45, 23 September 2024 (UTC)Reply

In Ukrainian Wikipedia, there is no expectation that pages are stabilised by default, so the page contents of /sandbox page display the unreviewed page. Template review status is tracked on pages transcluding the template that use FlaggedRevs. So User:Johnuniq/convert would also show the page with unreviewed edits while the mainspace page won’t. stjn 18:23, 24 September 2024 (UTC)Reply

Amazing, thanks. Johnuniq (talk) 21:20, 24 September 2024 (UTC)Reply

@Johnuniq Most of unreviewed changes are seen by unregistered user. It also doesn't depends if page has semi or full protection levels (however, to have fully protected page with unrewieved changes is rarest thing, because all administrator have rewiever rights). Only what matters is if a page has stabilization or not. Usually, if a page is highly proned to vandalism or have chosen as good article or featured article, administrator stabilize the page. In this case, all of unrewieved changes aren't seen by unregistered user. Usually, pages have special symbol to mark that they are stabilized, and the text on a save button would change from "save" to "write" or "write changes". Repakr (talk) 05:08, 24 September 2024 (UTC)Reply

Thanks. I've never seen that approach. I was wondering whether unregistered users would see the effect of an unreviewed change to a module or template. One day you might test that with a stabilized module but we have enough to think about before continuing this. Johnuniq (talk) 05:36, 24 September 2024 (UTC)Reply

This script doesn't seem active/working anymore. Can it be fixed? Or is there an identical script? Kailash29792 (talk) 07:11, 23 September 2024 (UTC)Reply

I would guess this broke with the headings change earlier this year. It should be fixable, but not by me. Izno (talk) 16:00, 23 September 2024 (UTC)Reply

Pinging @Amorymeltzer. --Ahecht (TALK
PAGE) 16:43, 23 September 2024 (UTC)Reply

Yeah, been bugging me too, thanks for the prompt Kailash29792. Should be working now. ~ Amory (u • t • c) 14:40, 25 September 2024 (UTC)Reply

are there any toolbar buttons or add-ins which can be used/ added for users to format cells in a table, like changing cell BG colour?
Anish Viswa 11:05, 23 September 2024 (UTC)Reply

No, and you should generally not want to change the background color of cells. See also WP:COLOR. Izno (talk) 16:01, 23 September 2024 (UTC)Reply

@Anishviswa See Template:Table cell templates/doc. --Ahecht (TALK
PAGE) 16:42, 23 September 2024 (UTC)Reply

This is not I am looking for. Is there some option in WYSIWYG editor (add a toolbar) to select and change BG color of a cell or group of cells, like in MS Excel ?
Anish Viswa 07:54, 25 September 2024 (UTC)Reply

MediaWiki message delivery 23:32, 23 September 2024 (UTC)Reply

@Quiddity (WMF) and SD0001: Regarding this change to syntaxhighlight, what would be the effect on pages like Help:Link and Help:Transclusion? Such pages have many examples of how wikitext is used, wrapped in <syntaxhighlight lang="wikitext">...</syntaxhighlight> where the intent is to show the markup and not the effect of using double square brackets and double braces. Will this be controllable with an attribute? If so, it should be opt-in, in order to not break all of the existing cases. --Redrose64 🌹 (talk) 06:56, 24 September 2024 (UTC)Reply

Links are only applied within text detected by the syntax highlighter as comments (<!-- ... --> for lang=wikitext). The change is already live – if you don't see any effect now, there is no effect. – SD0001 (talk) 07:20, 24 September 2024 (UTC)Reply

Example made with <syntaxhighlight lang="wikitext">...</syntaxhighlight>:

<!-- [[Alice]] is in a wikitext comment with lang="wikitext" so it is linked. It still displays the link brackets. -->
[[Boc]] is not in a comment so it is not linked.
// [[Carol]] is not in a wikitext comment so it is not linked. It is in a CSS/JavaScript comment so it would have been linked with lang="CSS" or lang="JavaScript"

PrimeHunter (talk) 11:27, 24 September 2024 (UTC)Reply

@PrimeHunter I'm not seeing any links in that example. Is there some preference that might be overriding it? --Ahecht (TALK
PAGE) 14:58, 25 September 2024 (UTC) Never mind, refreshing the page made the link show up. Must've been a glitch. --Ahecht (TALKReply
PAGE) 15:04, 25 September 2024 (UTC)

I've just created Category:Polish archivists, which is well developed at pl:Kategoria:Polscy archiwiści. I am sure some entries from the pl category have entries here on en already. Do we have a both that could populate our category based on what is on pl? Doing this kind of stuff manually is a chore I no longer enjoy, I am afraid. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:48, 24 September 2024 (UTC)Reply

@Piotrus I think this could be straightforward for a bot to accomplish when both categories are single level, i.e only articles, but not when there are child categogies. If there are subcategories, then it's not trivial and a bot could be disruptive. Imagine if we could add Category:Archivists from Poland (Q7604592) to an article subject, and it would populate specific language editions under certain conditions. I am holding out for wikidata improvements to address this. Ironically this convo will get archived by a bot later ;) ~ 🦝 Shushugah (he/him • talk) 11:18, 27 September 2024 (UTC)Reply

@Shushugah Fair point, I understand how subcategories could be messy. For now, however, a simple category copy of articles without dealing with subcategories would be much appreciated. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:21, 27 September 2024 (UTC)Reply

I'm unsure if this issue is known: I've reported it on Template_talk:Infobox_nutritional_value#Centre-aligned_labels_on_mobile_view_appear_haphazard and wondered if there should be a more general solution. Or is the different alignment intentional? Thanks, cmɢʟee⎆τaʟκ 14:43, 24 September 2024 (UTC)Reply

Most (if not all) browsers will centre-align table header cells by default: if left-alignment is desired, it needs to be explicitly stated. --Redrose64 🌹 (talk) 17:24, 24 September 2024 (UTC)Reply

Thanks, @Redrose64: What baffles me is why Desktop view left-aligns them in Template:Infobox_nutritional_value but Mobile view centre-aligns them. Any clue? cmɢʟee⎆τaʟκ 23:54, 24 September 2024 (UTC)Reply

I left a comment on the template talk page earlier about that. Izno (talk) 00:14, 25 September 2024 (UTC)Reply

For desktop view, MediaWiki:Common.css has this rule:

.infobox-label,
.infobox-data,
/* Remove element selector when every .infobox thing is using the standard module/templates  */
.infobox th,
.infobox td {
	/* @noflip */
	text-align: left;
}

The table header cells concerned match the first and third selectors here, so the declaration is applied to these cells. I don't think that Common.css is loaded in mobile view, so this rule is not applied. --Redrose64 🌹 (talk) 07:29, 25 September 2024 (UTC)Reply

Thanks for explaining, @Izno: and @Redrose64: I'll leave it as is and await a solution then. Cheers, cmɢʟee⎆τaʟκ 19:21, 25 September 2024 (UTC)Reply

I worked on this script years ago and it seems as if it has reached a mostly stable state. The script removes the "action=edit" from redlinks which essentially prevents the editor from auto-loading when clicking on non-existent pages that one has permission to create. I think this should be available as a gadget to allow for more configuration. Something like: Do not immediately enter editing mode when clicking on a red link.

Thoughts? Awesome Aasim 15:29, 24 September 2024 (UTC)Reply

It's hard to see why anyone would want it, even setting aside the fact it goes through every link on the page every tenth of a second. Nardog (talk) 12:45, 25 September 2024 (UTC)Reply

Not sure if the numbers at Wikipedia:User scripts/List are current, but if so it doesn't look like it has been picked up by many so far, so I don't expect many would opt-in. In general, we want people following a redlink to start a page. — xaosflux ^Talk 13:07, 25 September 2024 (UTC)Reply

Yeah, I am aware. This is so that it picks up links in VE previews, etc. Awesome Aasim 14:12, 25 September 2024 (UTC)Reply

@Awesome Aasim I haven't done much scripting around VE, but it seems like there should be a way to add an event listener to things like the VE preview window and only have it run when the content changes. --Ahecht (TALK
PAGE) 14:52, 25 September 2024 (UTC)Reply

Hmm... I am not sure... maybe someone more experienced with scripts knows... Awesome Aasim 05:55, 26 September 2024 (UTC)Reply

You wouldn't even need that; you can just attach an onclick listener to "a.new" elements and modify the href to remove &action=edit as they're being clicked, even if they've been dynamically added after page load. Writ Keeper ⚇♔ 06:13, 26 September 2024 (UTC)Reply

Oh! Let me try this. One second. Awesome Aasim 06:13, 26 September 2024 (UTC)Reply

Actually, I change my mind. Doing this would cause stuff like "open link in new tab" to not function correctly. I do hope there is something smarter. Awesome Aasim 06:15, 26 September 2024 (UTC)Reply

No, it works with new tabs just as well as anything else:

$("#mw-content-text").on("click","a.new", function(event){
  $(this).attr("href", $(this).attr("href").replace("&action=edit", ""));
})

The URL modification happens before the click, so if you CTRL+click or whatever to open a new tab, it gets the modified URL. Writ Keeper ⚇♔ 06:22, 26 September 2024 (UTC)Reply

What about links that are not in mw-content-text? For example, tabs and navbars? Awesome Aasim 06:24, 26 September 2024 (UTC)Reply

I'm not sure why you would have redlinks outside of mw-content-text, but if that were a concern, you'd just choose a node higher up than #mw-content-text. Writ Keeper ⚇♔ 06:25, 26 September 2024 (UTC)Reply

If a subject page has no talk page, the talk page tab appears as a redlink; similarly, if a talk page has no subject page, the subject page tab appears as a redlink. These tabs are outside mw-content-text. --Redrose64 🌹 (talk) 16:28, 26 September 2024 (UTC)Reply

Was the input box for Search the frequently asked questions in the help desk always this small? It has been squished by the button so much that it can't even display one character when I start typing.

Pretty sure it happens on any setting (even mobile), but I'm using Google Chrome on a computer. – 2804:F1...F5:930E (talk)00:45, 25 September 2024 (UTC)Reply

That's messed up. I am able to reproduce it in Chrome. In Firefox, the search button text says "Search the freque...". I have worked around it by allowing the button to be on a second line. I wonder if something changed in the code for <inputbox>...</inputbox>. – Jonesey95 (talk) 00:57, 25 September 2024 (UTC)Reply

Hmm, that's mw:Extension:InputBox? Doesn't seem like any related super recent changes there - there was an UI change in June though. I do not remember if Google Chrome ever displayed that search box correctly as I've only now paid conscious attention to it (and I don't frequent help desk, specially the top of the page, much).

The workaround is working though, thank you. – 2804:F1...F5:930E (talk) 01:09, 25 September 2024 (UTC)Reply

We could up width=30 to width=40 see if that's better? Moxy🍁 01:21, 25 September 2024 (UTC)Reply

After testing in preview at Wikipedia:Help desk/Header/sandbox, it seems that when I restore the break=no, even if I do width=500, or 50000, nothing actually changes from width=30...

Certainly seems like a bug. – 2804:F1...F5:930E (talk) 02:17, 25 September 2024 (UTC)Reply

The surrounding box is limited to 300px, so enlarging the width of the search box is probably limited by that. – Jonesey95 (talk) 02:24, 25 September 2024 (UTC)Reply

Well, without the break=no it does resize past the 300 (and all the way off the side of the screen), a width=3 also has no effect. They do change a size attribute in the input box, but I guess because of what Izno said below it just has no effect when the button is in the same line? – 2804:F1...F5:930E (talk) 02:47, 25 September 2024 (UTC)Reply

Yes, the June update to use Codex is likely what caused the situation, if anything caused it. The block at

form.mw-inputbox-form-inline { .cdx-text-input { min-width: auto !important; } }

is what causes the issue today, since it's assuming that the table width containing the whole input box is "king", more or less. And it wants to display the content from the button more than the non-content in the form input.

(Without that CSS line at your browser, this naturally stretches the table to allow display of both the input and button. That's a feature of web tables but it causes issues in other ways sometimes.)

Two ways to fix it probably without asking for a change upstream. One is to make the side box bigger. I wouldn't generally advise this, since that has knockon effects for use in mobile. The other is to put the input and the button on different lines. Izno (talk) 02:29, 25 September 2024 (UTC)Reply

Is there a gadget, user script or way to get a button to expand all headings in mobile view? It's annoying to have to manually expand them all when you want to do "find in page" or just simply want to see the whole article </MarkiPoli> <talk /><cont /> 11:44, 25 September 2024 (UTC)Reply

Yes, there's an option for that on Special:MobileOptions (accessible via top-left menu → Settings). [For anyone else reading this, note that the option only appears when using the mobile mode, and only on small-screen devices, since on larger devices the headings are already expanded.] Matma Rex talk 12:36, 25 September 2024 (UTC)Reply

Wow, never realised that! Although it doesn't seem to be a "button", just an option saying to expand all headings. That's fine, but a button would still be useful. Maybe someone could write a user script? </MarkiPoli> <talk /><cont /> 13:37, 25 September 2024 (UTC)Reply

The latest run of Special:WantedCategories features another cluster of template-autogenerated nonsense, resulting from something that was done around {{WikiProject U.S. Roads}} within the past couple of days, rating articles for the importance level of "¬". Obviously that's not a real thing we actually expect to have, and this results from a coding or spelling error somewhere, but as that template imports things from an outside module I can't find the error to fix it as it isn't in the primary template itself. So could somebody look into making the following redlinked nonsense categories go away?

• Category:¬-importance Road transport articles
• Category:¬-importance Massachusetts road transport articles
• Category:¬-importance New York road transport articles
• Category:¬-importance Pennsylvania road transport articles
• Category:¬-importance Connecticut road transport articles
• Category:¬-importance Iowa road transport articles
• Category:¬-importance Kansas road transport articles
• Category:¬-importance Maine road transport articles
• Category:¬-importance Minnesota road transport articles
• Category:¬-importance Missouri road transport articles
• Category:¬-importance New Hampshire road transport articles
• Category:¬-importance New Jersey road transport articles
• Category:¬-importance Oklahoma road transport articles
• Category:¬-importance Rhode Island road transport articles
• Category:¬-importance Texas road transport articles
• Category:¬-importance Wyoming road transport articles
• Category:¬-importance Delaware road transport articles
• Category:¬-importance Maryland road transport articles

Thanks muchly. Bearcat (talk) 18:32, 25 September 2024 (UTC)Reply

@Bearcat: At the moment, this isn't a VPT matter, because a group of people are presently working on WikiProject banners as a group. For instance, MSGJ (talk · contribs) has edited Template:WikiProject U.S. Roads only yesterday. You could send this somewhere like Module talk:WikiProject banner, perhaps. --Redrose64 🌹 (talk) 19:21, 25 September 2024 (UTC)Reply

That should be fixed now — Martin (MSGJ · talk) 21:07, 25 September 2024 (UTC)Reply

Do we have anything that shows word count in an article by section, similar to how Template:Section sizes shows size by byte for each section? If not, wouldn't this be helpful? Bogazicili (talk) 18:37, 25 September 2024 (UTC)Reply

Having a discussion at this talk page to build a calculator using waist circumference and height as an index for body "roundness", which is based on eccentricity and used for anthropometric assessment in health research, first reported here.

A draft exists. Adjustments are needed to provide both metric and imperial inputs, and two decimal points, and any gadget assuring simplicity for public use. The completed calculator will be presented in the article. A commercial example is on this site.

Would be grateful for ideas and solutions. Thanks. Zefr (talk) 20:03, 25 September 2024 (UTC)Reply

Bold solution: a zero input interface, no waist, no height to input, yet still provide the desired BRI: a table with waist left to right, height top to bottom, BRI in cells.

Uwappa (talk) 20:20, 25 September 2024 (UTC)Reply

Uwappa - thanks, although it isn't clear why 2 entries for waist and height are used, and the eccentricity factor is missing. Could you input data and show the result here? Also needed is the side-by-side display of metric and imperial results in 2 decimal places. See an example here (uses Wikipedia login to the medical wiki). Zefr (talk) 01:28, 26 September 2024 (UTC)Reply

The table was based on your "using waist circumference and height as an index for body "roundness", with waist and height being the two inputs and roundess the output.

You will have far more than 2 entries for both waist and height, hence the three dots.

The MDwiki asks for weight and height, not waist and height. Never mind, the idea is still the same: no input, do all computing in advance. No threshold, no effort required from readers. I've used your link to create the numbers for the example below, which will hopefully suffice to give you an idea for a similar table with waist and height as input.

An additional idea: take it one step further and answer the question that will be in the readers mind: Am I healthy?

Colour code the background, from green for healthy, via yellow to red for dangerous. A reader could look at the row close to own height and see multiple questions answered:

• Is my weight/waist in green, yellow or red?
• If yellow or red, what is the green value I should aim for?

Colour codes below are not based on real data, just an example.

	80 kg	90 kg	... kg
180 cm	24.7 kg/m2	27.8 kg/m2	...
175 cm	26.1 kg/m2	29.4 kg/m2	...
... cm	...	...	...

An even bolder proposal that will probably rock your boat, but anyway, based on your metric/imperial question: Keep the calculator for the medics and target the general audience while on Wikipedia. Boldly omit the numbers in the cells and show both metrics and imperial in row and column headers. The table will still answer the question in the readers mind: what waist/weight is healthy for me, given my height?

		80 kg	90 kg	... kg
		175 lbs	200 lbs	... lbs
180 cm	6 feet
175 cm	... feet
... cm	... feet

That might even allow to use both weight AND waist in the column headers and answer two questions: given my height, what weight and waist is healthy? — Preceding unsigned comment added by Uwappa (talk • contribs) 06:49, 26 September 2024 (UTC)Reply

I am reinventing the wheel. Please look at  . You could do all the computations behind it and create a similar chart for BRI. Uwappa (talk) 07:24, 26 September 2024 (UTC)Reply

This conversation, if it is not over, should probably move to Wikipedia talk:WikiProject Medicine. It does not appear to be a technical issue. – Jonesey95 (talk) 14:18, 26 September 2024 (UTC)Reply

I was trying to make that photo vector, but Ive gotten bored, maybe ill finish when I get around to it Anthony2106 (talk) 13:45, 28 September 2024 (UTC)Reply

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" [4] 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 Ladsgroup^overleg 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

As a continuation of this discussion Wikipedia:Village_pump_(technical)/Archive_215#New_gadget_for_doing_user_entered_calculations, I would like to see this gadget turned on by default for pages in the Category:Pages using gadget Calculator. Any concerns? Doc James (talk · contribs · email) 18:32, 26 September 2024 (UTC)Reply

See this in action on an article using this special url: https://en.wikipedia.org/wiki/Body_roundness_index?withgadget=calculator — xaosflux ^Talk 20:01, 26 September 2024 (UTC)Reply

Some feedback:

• As currently written this won't work in the official Wikipedia mobile apps or for anyone with JavaScript disabled or an older browser. This needs better fallback behaviour in my opinion before being enabled. [1] FWIW viewing it without the gadget I thought the page was broken and went to edit it.
• It seems to print NaN if I enter a waist figure but no height - this seems like a basic error that should be fixed.
• Switching between metric and imperial loses the form values - this doesn't seem like a very good user experience.
• Perhaps there should be a clearer way to report bugs and some more context explaining it - that might be a case of simply adding a caption.

Hope this is helpful.

[1] Note that anything that uses a template gadget will not work for anyone consuming our content outside English Wikipedia so that's something to bear in mind e.g. Wikiwand, apps, Google etc.. . At minimum I think this should provide some error message saying "This interactive element is not supported by your device." 🐸 Jdlrobson (talk) 00:44, 27 September 2024 (UTC)Reply

Excellent points Jdlrobson. Will work on building some of these. Doc James (talk · contribs · email) 02:49, 27 September 2024 (UTC)Reply

Most of that is already supported by the gadget, but needed some small changes to the specific wikipage template to work. [5]. Bawolff (talk) 03:41, 27 September 2024 (UTC)Reply

User:Jdlrobson does this address your concerns? Doc James (talk · contribs · email) 03:49, 27 September 2024 (UTC)Reply

For some reason, all clickable links that used to be gray have now become blue like normal links. This includes section links and the thank button, among other things. It also makes short descriptions blue when using the search feature. They are all still the correct color on the desktop version. Is this intentional, and if not, can it please be fixed? Thanks, QuicoleJR (talk) 20:46, 26 September 2024 (UTC)Reply

It also affects the notification when redirected to a different page, which is now hard to read because it is blue (or purple after clicked) on a black background. QuicoleJR (talk) 20:50, 26 September 2024 (UTC)Reply

@Jon (WMF). Izno (talk) 21:11, 26 September 2024 (UTC)Reply

+1 Mach61 23:56, 26 September 2024 (UTC)Reply

Confirming this new Thursday styling negatively affects UX legibility. Folly Mox (talk) 00:05, 27 September 2024 (UTC)Reply

We're aware of a few issues which seem to cover the situations you describe above:

• phab:T375834
• phab:T375833
• phab:T375832

Let me know if there are any issues not covered by the bugs above. If so, please be specific and at minimum include URLs and description of area, and steps you followed. If you can please provide a screenshot (you can use phabricator upload if needed).

We are looking to get these fixed next week. Jon (WMF) (talk) 00:35, 27 September 2024 (UTC)Reply

Have we always had two separate notices when editing an old revision of an article? If so, why? If not, what was changed and when? ElKevbo (talk) 23:07, 26 September 2024 (UTC)Reply

See other pic. — xaosflux ^Talk 00:34, 27 September 2024 (UTC)Reply

The first box shows MediaWiki:Revision-info which is also shown when the revision is viewed. We have customized it. The MediaWiki default at MediaWiki:Revision-info/qqx is much shorter. The second box shows MediaWiki:Editingold. The MediaWiki default MediaWiki:Editingold/qqx is a little shorter. The defaults have no overlap in content. PrimeHunter (talk) 10:32, 27 September 2024 (UTC)Reply

Thanks for the quick and helpful replies! I must have seen these so many times that they don't even register with me anymore.

The two notices do seem to be duplicative but this is not a hill I'm going to die on. Cheers! ElKevbo (talk) 14:02, 28 September 2024 (UTC)Reply

There is a maintenance category Category:Wikipedia articles with colour accessibility problems containing articles that have the templates {{overcolored}} or {{overcoloured}}. The maintenance category appears to have been created by including the {{DMCA}} template in the definition of {{overcoloured}}.

However, multiple templates also have this template, for example, {{Transport in Mexico City}}. The maintenance category does not seem to include templates. (Note: I recently added the {{overcoloured}} template to that template, but have since visited Special:Purge to purge both {{Transport in Mexico City}} and Category:Wikipedia articles with colour accessibility problems. Despite this purge, {{Transport in Mexico City}} does not appear on Category:Wikipedia articles with colour accessibility problems. So it seems that {{DMCA}} is specific to articles. There also does not seem to be an existing {{DMCT}} template to allow {{overcoloured}} to create Category:Wikipedia templates with colour accessibility problems.

Is this a Phabricator feature request that I need to file? Or is there somewhere else I need to request this?

Credit to Remsense for suggesting creating the Wikipedia templates with colour accessibility problems category.

Thisisnotatest (talk) 08:27, 27 September 2024 (UTC)Reply

I've raised a similar situation at Template:Unreferenced. This is because the templates use Template:Ambox. Creating an exact duplicate template just so other namespaces can be categorized is a horrible idea. Instead, the system behind categorization at the base level should be changed. The template shouldn't care which namespace it is placed on for categorization. Gonnym (talk) 09:53, 27 September 2024 (UTC)Reply

Some categories are intended for articles only, thus {{Dated maintenance category (articles)}} (abbreviated {{DMCA}}). A category named Category:Wikipedia articles with colour accessibility problems is probably of this type. A category that can contain any kind of page would probably begin with "Wikipedia pages" instead (e.g. Category:Wikipedia pages with colour accessibility problems).There are a few variations for other cases, such as {{Dated maintenance category (files, articles, categories, and templates)}}, as well as {{Dated maintenance category}} ({{DMC}}) that doesn't do any namespace checks. The last can be used along with templates like {{Main other}}, {{Namespace detect}}, and similar templates if you need something more complex, for example if you really want Category:Wikipedia templates with colour accessibility problems, Category:Wikipedia categories with colour accessibility problems, and so on. Anomie⚔ 11:25, 27 September 2024 (UTC)Reply

@Anomie: Aha! So the capability already exists! So what I need to do is update the talk page of {{overcoloured}} to suggest replacing the use of {{DMCA}} with {{DMC}} or {{DMCFACT}} since I believe we would want to track all or most overcolored situations, not just those occurring on articles, and attempt to get consensus on that change to the template. Thank you! Considering this matter solved. Thisisnotatest (talk) 20:01, 27 September 2024 (UTC)Reply

when I saw DMCA... I was thinking what has led to people filing DMCA requests on Templates here. – robertsky (talk) 14:27, 27 September 2024 (UTC)Reply

@Thisisnotatest: If something is wrongly categorised, and there is a possibility that the cat is due to the effects of a template, a purge won't help because it doesn't update the link tables. A WP:NULLEDIT is the thing to try. --Redrose64 🌹 (talk) 17:23, 27 September 2024 (UTC)Reply

@Danny Benjafield, in the future, try to avoid color, or use one of the Codex tokens directly (with a fallback). Thanks! Izno (talk) 19:59, 27 September 2024 (UTC)Reply

Is there a way to provide a permalink to Village pump topics which will survive the topic being archived? Thisisnotatest (talk) 00:14, 28 September 2024 (UTC)Reply

Permalinks always survive archiving, as they are links to a specific revision, for example this this is the permalink to the revision prior to my response. — xaosflux ^Talk 00:24, 28 September 2024 (UTC)Reply

This question actually calls out one of the problems with organization of talk pages and any other kind of page that effectively tries to track multiple topics on a single page, particularly when they are used for the purpose of "cases" which have their own individual "lives". When you get a permalink, that lets you view the state of the page at some point in time. So if you get a permalink for such a page at some instant in time, you can see the case of interest at that point in time. You can link forward to the following version of that page, but there may have been no change to the case you're interested in. You might need to go through large numbers of versions for which the case you're interested in hasn't change. To find it just before it got migrated to an archive could have involved hundreds of versions. Of course, you can check the archive, but there could have been versions where content which was added but subsequently deleted, so you wind up having to look at numerous versions that did not affect the topic you're interested in. This is just an inherent limitation of the way that talk pages are managed. — Preceding unsigned comment added by Fabrickator (talk • contribs) 00:42, 28 September 2024 (UTC)^<diff>Reply

Confirmed. I'm looking for a link which will always link to the current state of the topic without regard to whether the topic has been archived or had subsequent updates. Thisisnotatest (talk) 02:45, 28 September 2024 (UTC)Reply

@Thisisnotatest: It is presently in place, but relies on several factors. First, people must always make links to the thread using normal Wikilinks (i.e. [[Wikipedia:Village pump (technical)#Village pump permalinks?]]) and not external links (i.e. [https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Village_pump_permalinks%3F]), regardless of the page where those links are made. Second, the VP page must be set up for archiving by ClueBot III (talk · contribs) (this is the case for WP:VPM and WP:VPW but not for VPI, VPP, VPR or VPT which all use lowercase sigmabot III). Third, other forms of archiving (whether manual, script or bot) must not be used on the VP page. If all of these are observed, ClueBot III will fix inward links to threads as and when they are archived, see for example these edits. --Redrose64 🌹 (talk) 10:02, 28 September 2024 (UTC)Reply

If you click on the timestamp for any comment, such as the first comment in a section, a link to that comment will be copied to the clipboard. When in future this section is archived, then when the link is followed, MediaWiki will display a popup message, with a link to the new location of the comment in the archive. See mw:Help:DiscussionTools § Talk pages permalinking for more details. (If you would like the link in wikitext format rather than an URL, you can try my user script to copy comment links to the clipboard to save you the work of adjusting the URL.) isaacl (talk) 05:02, 28 September 2024 (UTC)Reply

@Isaacl: Thank you, that's perfect, especially as I would ususally be linking to my first comment. Thisisnotatest (talk) 06:04, 28 September 2024 (UTC)Reply

Keep in mind, those such links are much more fragile than actual permalinks. — xaosflux ^Talk 09:50, 28 September 2024 (UTC)Reply

It's a tradeoff. A link to an actual page version won't get affected by subsequent edits, while the new talk page comment permalink feature relies on the content not being deleted without being moved, and the relevant signatures not being modified, to gain the benefit of linking to a specific comment with later responses also being shown. isaacl (talk) 17:24, 28 September 2024 (UTC)Reply

Monobook, Edge, Win11. Navigation popups gadget. When I point my mouse at Jon Anderson, instead of the expected preview I see }}. DuncanHill (talk) 01:18, 28 September 2024 (UTC)Reply

FWIW it seems to be related to when the infobox is complicated with a module loading another box in the first infobox. Probably just beyond popups' ability to render that deep. — xaosflux ^Talk 10:12, 28 September 2024 (UTC)Reply

With window.popupPreviewFirstParOnly = false; in the browser console I see }} and below it the opening paragraph. Popups apparently misreads the complicated infobox as an opening paragraph only containing }}. {{ and }} are correctly balanced in the article. PrimeHunter (talk) 11:56, 28 September 2024 (UTC)Reply

Do we have an edit filter that warns people who enter Wikipedia as a citation? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 28 September 2024 (UTC)Reply

Yes, see 1057 (hist · log). -- zzuuzz ^(talk) 12:40, 28 September 2024 (UTC)Reply

What happened to the categories at the bottom of articles on the mobile version of the site? You finally added them, then they disappeared for a while, then they came back, then they disappeared for good and that was years ago. Please bring them back and keep them there, there is no reason to not have them there and it is extremely inconvenient 2603:7080:8140:8A60:14E:FF29:2359:5592 (talk) 12:42, 28 September 2024 (UTC)Reply

Categories are not displayed in the mobile version. Mobile users can click "Desktop" at the bottom of a page to see the desktop version with categories. Registered users can enable Advanced mode which includes a "Categories" button. PrimeHunter (talk) 13:08, 28 September 2024 (UTC)Reply

I added that to Help:Categories in 2021 [6] but it appears the categories are now displayed all the time in advanced mode. PrimeHunter (talk) 13:14, 28 September 2024 (UTC)Reply

How can Special:CiteThisPage be updated? Is a Phabricator ticket required? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:50, 28 September 2024 (UTC)Reply

Administrators can edit MediaWiki:Citethispage-content. You can make edit requests on the talk page. PrimeHunter (talk) 13:03, 28 September 2024 (UTC)Reply

iOS Safari browser: NewUsers seems to have recently had a change so that all users’ contribs pages are blue-linked, whether they’ve made an edit or not. I foresee this increasing UAA reports that get a   Wait until the user edits. response. Is there a way to get around this? MM (Give me info.) ^(Victories) 14:45, 28 September 2024 (UTC)Reply

Can you be more specific about the page you are referring to? the user creation log doesn't seem to be doing this in a couple of different views I tried. — xaosflux ^Talk 15:05, 28 September 2024 (UTC)Reply

Okay, for example.

16:22, 28 September 2024 User account Karen8907 talk contribs was created

’contribs’ used to be red, if the user had made no edits. Now they are all blue, whether there’s an edit or not. Does that make more sense?

I have ‘advanced mode’ on. Is that likely to be anything to do with it? MM (Give me info.) ^(Victories) 15:24, 28 September 2024 (UTC)Reply

When logged out, at mobile view, I only see blue contribs links; at desktop view most are red. So "advanced mode" (whatever this is) is not a factor. --Redrose64 🌹 (talk) 16:02, 28 September 2024 (UTC)Reply

If the user has no edits then the contribs link has the class mw-usertoollinks-contribs-no-edits in both desktop (tested in Vector legacy) and mobile, but only desktop has this CSS:

.mw-usertoollinks-contribs-no-edits {
  color: #ba0000;
}

You can add the following to your CSS to get red links in all skins assuming they add the class:

.mw-usertoollinks-contribs-no-edits {
  color: #ba0000 !important;
}

PrimeHunter (talk) 16:36, 28 September 2024 (UTC)Reply

Code’s done the trick. BigThank, Prime. MM (Give me info.) ^(Victories) 16:57, 28 September 2024 (UTC)Reply

WMF recently changed link colors on Minerva and I suspect this is another casualty (or was a delta that always existed and shouldn't have). @Jon (WMF) Izno (talk) 16:48, 28 September 2024 (UTC)Reply

Just as a heads up, my skin is Vector (2022), not MinervaNeue. MM (Give me info.) ^(Victories) 16:59, 28 September 2024 (UTC)Reply

You linked the mobile site above and claimed to be on iOS. You cannot today select a skin for mobile website: you are always on Minerva. Izno (talk) 17:08, 28 September 2024 (UTC)Reply

It was xaosflux who linked mobile but MM is probably there. "Advanced mode" is a feature of the mobile version at https://en.m.wikipedia.org/wiki/Special:MobileOptions. Mobile devices usually pick the mobile version by default regardless of your skin. You can switch at "Desktop" or "Mobile view" at the bottom of pages. If it says "Desktop" then you are currently on mobile, also called Minerva. PrimeHunter (talk) 17:15, 28 September 2024 (UTC)Reply

And indeed, the CSS that should be activating is

.mw-usertoollinks-contribs-no-edits {
  color: var(--color-destructive,#d73333);
}

And which is instead being overridden by

a:not([role="button"]):not(.minerva__tab-text) {
  color: var(--color-progressive,#36c);
  border-radius: 2px;
  text-decoration: none;
}

likely due to specificity, since :not() adds to the specificity. Izno (talk) 17:11, 28 September 2024 (UTC)Reply

If I open a new topic on a talk (such as I have just done here) the software won't let me abandon it. It wants me to finish it. Like, suppose right now I decided "enh this isn't right venue" and left the page discarding my work (or wishing to). Well if I come back to this page tomorrow, it won't let me start a new thread, or edit an existing thread, or even read the page. Nope. It's like "You started a thread yesterday. I'll take you there now! FINISH IT AND POST IT chum and then we can talk about what I'll allow you do to next."

Mind you this is after I have clicked the "OK" on "Leave this page? Your work will be lost" box (that is generated by Firefox not Wikipedia). There it is again when I come back. I can erase the text, but can't entirely erase the title ("You can't have a blank title!") nor delete the thread. I suppose if I were to drop dead it would start harassing my estate to finish the post, I don't know.

This is no good. Can this be fixed? Is there a workaround? Fixing would better as that'd mean future editors would not have to climb the draperies. Thanks. Herostratus (talk) 17:34, 28 September 2024 (UTC)Reply

The yellow box that says This is only a preview; your changes have not yet been saved! when you preview your edit doesn't seem to be showing up for me. Instead, the message is just shown in plain text under the "Preview" header, which makes it seem like it is part of the actual text. Was this an intentional change? The box appears normally when signed out. InfiniteNexus (talk) 18:52, 28 September 2024 (UTC)Reply