Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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

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

New gadget for doing user entered calculations

We at Wiki Project Med are working to build mediawiki based calculators. One can be seen here on MDWiki mdwiki:Body_mass_index.

Within medicine there are hundreds of such calculators.[1]

Wondering about getting this functional here as a trial? More development is going to be required before this is extensively used of course.

We would need an interface admin to copy this over for it to work. Doc James (talk · contribs · email) 06:33, 4 September 2024 (UTC)

I don't see any calculator on mdwiki:Body_mass_index? – SD0001 (talk) 14:36, 4 September 2024 (UTC)

Do you see it on mdwiki:Template:Calculator#Example ? Bawolff (talk) 15:10, 4 September 2024 (UTC)

On that remote wiki I see it labeled as "BMI calculator". — xaosflux ^Talk 15:17, 4 September 2024 (UTC)

ah never mind, for some reason I had JS disabled on the site. – SD0001 (talk) 15:58, 4 September 2024 (UTC)

Baring any actual objections to testing I'm not seeing any showstoppers to forking over as an opt-in/?withgadget test. — xaosflux ^Talk 17:12, 4 September 2024 (UTC)

Thanks Xaosflux. Have built another example here mdwiki:CHA2DS2–VASc score. Once we have a testable version on EN WP will be easier to discuss with others who may be interested. Doc James (talk · contribs · email) 07:38, 5 September 2024 (UTC)

I feel like specifying formulas inline could be susceptible to subtle vandalism which would be undesirable. I'm also seeing mentions of eval, can you comment on how this calculations are being done ? (I'll note evaling user-generated content on Wikimedia sites should probably be a no-go from a security POV). Sohom (talk) 16:57, 5 September 2024 (UTC)

Everything on Wikipedia is susceptible to vandalism; it doesn't mean we stop mentioning people's birth dates and other details which can be subtly fabricated. The calculators could be made templates which can be protected if necessary. Evalling is fine if inputs are sanitised. – SD0001 (talk) 17:10, 5 September 2024 (UTC)

@SD0001 Wrt to the first point, my thought process was that manipulating birthdays would be a lesser issue than manipulating a BMI calculator that could be potentially be used by people to self-diagnose metabolism disorders. Regarding the rest, on looking further at the code, I agree that security shouldn't be a issue for it's current version, however, it would be nice to document the method the script uses anyway (as a comment) to make sure future editors of the script are aware of this consideration. Sohom (talk) 19:33, 5 September 2024 (UTC)

The tl;dr is that the formulas are parsed using a simple Recursive descent parser into an AST type structure. The AST is evaluated by walking through the tree. In the tree there are OP nodes that represent an operation from a fixed set of valid operations implemented in javascript. A dependency graph structure is also created in order to refresh any widgets that depend on a value that was changed with loop detection. Bawolff (talk) 19:41, 5 September 2024 (UTC)

I added a code comment to the script. Bawolff (talk) 19:53, 5 September 2024 (UTC)

@Sohom Datta this would serve the user some javascript, execution is client-side via browser. The script code itself could only be modified by interface admins. The current script would always be viewable by anyone, and is currently available to see at this link. — xaosflux ^Talk 19:30, 5 September 2024 (UTC)

The script does not use eval() as a security precaution. It is designed with security in mind. Bawolff (talk) 19:31, 5 September 2024 (UTC)

See my comment just above regarding this, I agree that is probably safe, but it would make sense to document the security considerations in the code for future interface admins/script editors. Sohom (talk) 19:36, 5 September 2024 (UTC)

I have made some enhancements to User:SDZeroBot/Gadget sync so that it also supports wikis with a non-local interwiki mapping (like mdwiki). Could be used for this. – SD0001 (talk) 08:24, 10 September 2024 (UTC)

• Not seeing any blockers to testing, will work on import/setup. — xaosflux ^Talk 14:54, 11 September 2024 (UTC)

Last few sections at Wikipedia:Redirects for discussion appear as links instead

Figured this would be the place to see if anyone knows what's going on. Historically, Wikipedia:Redirects for discussion has been a rather expensive page, processing-wise, But what is currently going on has not happened at any point recently. The bottom-most sections are appearing as links instead of sections. This was not the case a few weeks ago. Does anyone know what's going on? Steel1943 (talk) 22:29, 4 September 2024 (UTC)

See WP:PEIS. – Jonesey95 (talk) 23:13, 4 September 2024 (UTC)

It's been categorized as >2,000,000 PEIS since 01:00, 2 September 2024 [2] and as >500 expensive parser calls since 02:28, 2 September 2024 [3]. Anything happen just over 3 days ago? SilverLocust 💬 02:38, 5 September 2024 (UTC)

Though the reason why the expensive parser function limit was hit is simple enough. There are >500 redirects currently nominated, and therefore >500 instances of

* {{no redirect|...}} → [[...]]

And {{no redirect}} uses an expensive parser function. SilverLocust 💬 04:41, 5 September 2024 (UTC)

This happened to us a few years ago at TFD when we embarked on a project to delete a few thousand unused and redundant templates. We had to slow down our nominations and list some of them on subpages. – Jonesey95 (talk) 05:02, 5 September 2024 (UTC)

Listing redirects at RfD should have a simpler template which just generates the link without checking anything. Johnuniq (talk) 06:03, 5 September 2024 (UTC)

The inexpensive alternatives are (1) a non-redirecting link that doesn't turn red after the RfD is closed as "delete" (or it's otherwise deleted), or (2) a normal wikilink that doesn't prevent redirection once the RfD is closed as "keep" (or the RfD banner is removed). SilverLocust 💬 07:15, 5 September 2024 (UTC)

Option (3) would be to just have both links, i.e. "Terrorblade (no redirect)". It's a low-tech solution but it may be good enough? Matma Rex talk 13:26, 5 September 2024 (UTC)

One could hide the second link if the first doesn't have the mw-redirect class in TemplateStyles. Nardog (talk) 13:28, 5 September 2024 (UTC)

Unless {{No redirect}} gets updated in a way that prevents expensive parser calls, I think either Option 2 or weak Option 3 is the winner there. The redirection should be prevented when the discussion is in progress due to the substitution of {{Redirect for discussion}} on the nominated redirect(s), and the option also allows the link to be red on the RfD if the redirect ends up being deleted. I can see a reason to have both links though, so my "weak option 3", but I don't see that option incredibly user-friendly as option 2. Steel1943 (talk) 19:46, 6 September 2024 (UTC)

Also, this discussion may need to be moved to Template talk:Rfd2 at some point if this discussion gets large. Steel1943 (talk) 19:56, 6 September 2024 (UTC)

Dark mode when logged out of 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)

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)

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)

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)

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

Navigation icons have vanished

Using Firefox and Dark Reader with Light Mode on, the icons are the same hue as the background and are not visible.

Fix by using Wikipedia's new Dark Mode? Not so fast. The background is too dark and the text is too bright. My eyes hurt when looking at it, and they don't hurt when using Dark Reader. This issue has already been raised by multiple users,[4] and will no doubt be solved in a timely fashion. But until then it would be nice to hit the undo button on whatever happened this week to the icons.

Here is some color data:

Wikipedia dark mode - harsh contrast

icons 234 236 240 Luminosity: 93%

back 16 20 24 Luminosity: 8%

Dark reader - easy on the eyes

text 232 230 227 Luminosity: 90%

back 24 26 27 Luminosity: 10%

This broke only a few days ago. Before, the icons were mostly correct except for the drop-down arrows. Wizmut (talk) 02:56, 6 September 2024 (UTC)

Possibly phab:T374180 which is now fixed. 🐸 Jdlrobson (talk) 00:31, 10 September 2024 (UTC)

Still broken. Is there a better place to report this issue? Wizmut (talk) 00:49, 10 September 2024 (UTC)

Technical Powers to "Block"

As my account has now been "blocked" - I began to ponder, peacefully - if Wikipedia has a forum of experts who deliberate as a technical team to "block or not" or is it an individual who decides and activates a "block" on a fellow wikipedian? I will patiently await a response or redirect to an article addressing my concerns. ZAWADI NPC (talk) 07:57, 6 September 2024 (UTC)

See WP:BLOCK for more information about the blocking process. 331dot (talk) 08:26, 6 September 2024 (UTC)

Your account is not blocked, ZAWADI NPC (as evidenced by your ability to post here). Why do you think it is? It has never been blocked. Bishonen | tålk 08:31, 6 September 2024 (UTC).

Their user page was deleted, maybe they think that is a block? 331dot (talk) 08:34, 6 September 2024 (UTC)

You were advertising on your page. Advertising is not allowed on Wikipedia, not even on your page. You don't own that page – it is only there to show people what kind of Wikipedia editor you are, not anything about your business. You may say something about hobbies or interests that you don't get money from, for example if you take great photographs and put them on Wikipedia (for free of course), then you can say so. TooManyFingers (talk) 19:23, 7 September 2024 (UTC)

Advanced Mode issues

I have been having this issue for a while now and would like some help solving it. I use Advanced Mode as a mobile user. Occasionally, going to some pages in the Wikipedia or User namespaces will show me the non-Advanced Mode UI. Going to another page typically fixes this, and going into Settings shows that Advanced Mode is still turned on. This seems to happen most often when clicking a link from one Wikipedia namespace page to another page in that namespace, but will sometimes also happen in other circumstances. There is no visible pattern to when it happens. Does anyone know why this happens or how it can be fixed? Thanks, QuicoleJR (talk) 14:42, 6 September 2024 (UTC)

Which mobile client type (Apple, Android) and Version are you using? — xaosflux ^Talk 14:46, 6 September 2024 (UTC)

Using the mobile browser version on an iPhone. I'm not sure what you mean by version. QuicoleJR (talk) 14:51, 6 September 2024 (UTC)

@QuicoleJR thank you, was clarifying if you were using the browser or the Wikipedia App. For your browser, assuming you are using Safari? Are you using the current version of Safari? — xaosflux ^Talk 14:55, 6 September 2024 (UTC)

Actually, no, I do not use Safari. I use the Google app (not Google Chrome, Google itself). I am using the current version of Google AFAICT. QuicoleJR (talk) 15:01, 6 September 2024 (UTC)

To verify if this is some browser problem, can you try again using a different browser? — xaosflux ^Talk 10:09, 11 September 2024 (UTC)

Ok. I will ping you after I do that. QuicoleJR (talk) 12:05, 11 September 2024 (UTC)

@Xaosflux: I tried using Safari and encountered the same issue. It seems to be most common with FACs. QuicoleJR (talk) 12:08, 11 September 2024 (UTC)

@QuicoleJR when browsing are you logged in? Non-logged in users may get cached versions of pages. — xaosflux ^Talk 13:17, 11 September 2024 (UTC)

Yes, I always use Wikipedia logged-in. QuicoleJR (talk) 13:26, 11 September 2024 (UTC)

Map labels unreadable in dark mode

Given the number of transclusions on Template:Infobox settlement, it looks like the problem reported at Template talk:Infobox settlement#Location labels unreadable in dark mode is affecting over half a million articles for anyone reading in dark mode. Does anyone feel competent enough to poke around the CSS? -- Beland (talk) 06:44, 7 September 2024 (UTC)

templatedata not showing up

i have added templatedata to Template:Infobox card game. why isn't it showing up when editing, say, whist? ltbdl☃ (talk) 08:58, 7 September 2024 (UTC)

That's weird. Izno (talk) 16:23, 7 September 2024 (UTC)

Works for me. I null-edited the Infobox template. Editing the /doc template should, in a perfect world, immediately provide a null edit to the single page that transcludes it, but it rarely does so. – Jonesey95 (talk) 22:25, 7 September 2024 (UTC)

I was able to reproduce earlier in Firefox up to date, but no longer. Maybe indeed it was a question of needing a null edit. Izno (talk) 22:39, 7 September 2024 (UTC)

No search box for default skin

The search box at the top of the main page en.wikipedia.org is absent on the default skin, at least on certain browsers. There is an empty area where it would belong, but there's nothing visible or clickable there. This happens at least on some versions of Chrome. The default skin on mobile is still working fine. On desktop, switching skins fixes the problem. Could this be dark mode related? TooManyFingers (talk) 16:39, 7 September 2024 (UTC)

I found my problem.

1. Clicking the magnifying glass icon is now required, to use the search box.

2. My magnifying glass is not visible in dark mode. But it's there and I can click on it. TooManyFingers (talk) 17:19, 7 September 2024 (UTC)

Clicking the icon should be required only at smaller resolutions. But it should still be visible, so something there is weird. Izno (talk) 18:39, 7 September 2024 (UTC)

Another user who's not on dark mode says the magnifying glass is invisible or barely visible for them too. So it's not just dark mode. TooManyFingers (talk) 19:07, 7 September 2024 (UTC)

Several similar complaints at WP:Help desk recently. Gråbergs Gråa Sång (talk) 09:30, 8 September 2024 (UTC)

An example: Wikipedia:Village pump (technical)/Archive 213#Search box. —⁠andrybak (talk) 09:36, 9 September 2024 (UTC)

Current date templates break after entering source editor

The default template for dating tags Template:Currentyear and Template:Currentmonth turn into a nowiki format after entering and exiting source. Roasted (talk) 00:52, 8 September 2024 (UTC)

Aren't they supposed to do that? They mean "today as I am writing", not "today as someone is reading 30 years later" ... TooManyFingers (talk) 06:19, 8 September 2024 (UTC)

@Roastedbeanz1: Your post could refer to different situations. Describe what you did from the start, what you expected and what happened instead. Save and link an edit where it happened. If you tried to add templates using source code like {{...}}} in VisualEditor then it's not supposed to work. VisualEditor has its own way of adding templates. See Help:VisualEditor#Editing templates. PrimeHunter (talk) 09:20, 8 September 2024 (UTC)

PXPX issue with GALLERY tag

Tracked in Phabricator
Task T374311

I noticed that my userpage was in Category:Pages with image sizes containing extra px. As it turned out, this was because I had specified |widths=80px. Removing the px solved it. This appears to be a WP:PXPX issue. Checking a random sample of a dozen pages of the currently 8k+ in the category, I found that, in all cases, the member pages had the exact same issue with |widths= and/or |heights= specifications. Paradoctor (talk) 10:25, 8 September 2024 (UTC)

This is phab:T374311. I think it has always been suggested to include px in gallery sizes but now it adds the new tracking category. I think the gallery tag or tracking code should be modifed to allow one px in gallery wikitext without triggering the category, rather than mass-removing old px from all wikis to avoid the category. The suggestion to include px was removed from mw:Gallery examples yesterday and today.[5] PrimeHunter (talk) 12:49, 8 September 2024 (UTC)

This category appears to be broken at this time (false positives on properly configured gallery tags, per long-standing documentation at mediawiki.org), and possibly not needed at all, since Linter started detecting pxpx errors in 2023. I have commented at two related Phab tasks. – Jonesey95 (talk) 00:48, 10 September 2024 (UTC)

Yeah, sorry about that. Fix in gerrit, but it did uncover the fact that the 'px' suffixes weren't being localized properly on non-English wikis. C. Scott Ananian (WMF) (talk) 14:47, 11 September 2024 (UTC)

Gallery within mediawiki core itself does add an "px", so there definatly is an "pxpx" when the user gives one too. See for example https://gerrit.wikimedia.org/g/mediawiki/core/+/4d588557172511e7931bcdb63a87e9a6281c8cb3/includes/gallery/TraditionalImageGallery.php#65. That hardcoded px in code should go away, this is usually a bad practice anyway. It could also open the possibility of other units in galleries, but given that this has been hardcoded for years, it is most likely not tested at all. Snævar (talk) 14:13, 10 September 2024 (UTC)

Color me confused. When I run

<gallery widths=180px>
foo.jpg
</gallery>

through Special:ExpandTemplates and ask it to show me the raw HTML, I see

<div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr"><ul class="gallery mw-gallery-traditional">
		<li class="gallerybox" style="width: 215px">
			<div class="thumb" style="width: 210px; height: 150px;"><span typeof="mw:File"><a href="/wiki/File:Foo.jpg" class="mw-file-description"><img src="//upload.wikimedia.org/wikipedia/commons/thumb/0/06/Foo.jpg/180px-Foo.jpg" decoding="async" width="180" height="118" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/0/06/Foo.jpg/270px-Foo.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/0/06/Foo.jpg 2x" data-file-width="300" data-file-height="197" /></a></span></div>
			<div class="gallerytext"></div>
		</li>
</ul></div>

I don't see any pxpx in there. I agree that any hardcoded px should go away and live in the "gallery" declaration. That might allow us to use other units like em with code like "widths=10" being ambiguous. – Jonesey95 (talk) 01:31, 11 September 2024 (UTC)

gallery tags are not template-expanded to other wikitext so Special:ExpandTemplates doesn't show it but there is an internal MediaWiki process which adds px before passing code from gallery tags to other parts of MediaWiki. phab:T374311#10137524 says a patch has been uploaded today. It has to be approved and deployed but I suggest we just wait and ignore the tracking category for now. Category:Pages with image sizes containing extra px already has a note [6] about it. PrimeHunter (talk) 16:04, 11 September 2024 (UTC)

Auto-expand "Learn more about this page" on navigation to anchor

This is with reference to the trouble a user reported at Talk:Turkey#Extended-confirmed-protected edit request on 12 August 2024 and similar reports I've seen elsewhere. In mobile view, the tags at the top of a talk page are hidden under an expandable link reading "Learn more about this page". These tags may include, among other things, a FAQ tag. When, in a discussion on the page, we want to route an inquiring editor to the FAQ (such as to Talk:Turkey#FAQ), we can't do so for a mobile user because the link doesn't work and the user, even if they scroll to the top (which is now the second thing they've tried in their attempt to see the referenced material), don't see the FAQ and don't see the third thing, clicking "Learn more about this page" that they'd have to do to get there, or perhaps at that point they've already given up.

Is it possible through some feat of CSS and/or Javascript wizardry to cause the top material to expand automatically upon navigation to an anchor that's within it? Largoplazo (talk) 17:31, 8 September 2024 (UTC)

Why isn't this valid CSS?

The problem I'm having is actually on wikiconference.org, not here, but I'm asking this here because this is where all the really smart people hang out :-)

I'm trying to generate some custom CSS for https://wikiconference.org/wiki/2024/Schedule which will let me highlight the talks I want to go to. this works, but only highlights the talk title. this one highlights every table cell (as expected). this one does exactly what I want (i.e. highlights the table cell containing the desired title), but when I go to save it, I get an error message "The document contains errors. Are you sure you want to save?" and "Error: Expected RPAREN at line 1, col 9". Ignoring the error message and clicking "OK" seems to work fine.

Is this really invalid CSS, or is the editor just giving me a bogus warning? RoySmith (talk) 14:06, 9 September 2024 (UTC)

The editor is older than the CSS you're employing. Izno (talk) 15:54, 9 September 2024 (UTC)

Thanks. As far as I can tell, :has() was introduced in 2018, but I guess that's not a long time by wiki standards. RoySmith (talk) 16:31, 9 September 2024 (UTC)

:has() was first-implemented in 2022 by Safari, then Chromium, then late 2023 by Firefox (implementing it was non-trivial for performance reasons), and I think went through a few name changes between 2018 and 2022. I am not surprised that the editor doesn't know it. Izno (talk) 16:41, 9 September 2024 (UTC)

@RoySmith: The W3C doc that you link is a Working Draft, which is a long way from being a Recommendation. The :has() pseudo-class is not part of the Selectors Level 3 spec, which is a W3C Recommendation. --Redrose64 🌹 (talk) 19:00, 9 September 2024 (UTC)

Thank you. RoySmith (talk) 19:43, 9 September 2024 (UTC)

Special:Preferences sticky table header hides first data row

Originally reported in Phabricator but closed as "invalid" because "this is a local gadget". https://phabricator.wikimedia.org/T374327

Basically, enabling "Make headers of tables display as long as the table is in view" in Special:Preferences Gadgets results in the first table data row in templated tables being hidden by the table header rows shifted down. See Phabricator ticket for example and screenshots. ~Anachronist (talk) 14:19, 9 September 2024 (UTC)

Interestingly, it displays properly in Chrome if my window is about half the width of the screen, or if I turn on Developer Tools so that the display area is about half the width of the screen. --SarekOfVulcan (talk) 14:28, 9 September 2024 (UTC)

Your Phabricator example is Template:Series overview/doc. That template has code which works poorly with the gadget. See MediaWiki talk:Gadget-StickyTableHeaders.css#Not working at The Economist Democracy Index#List by region. PrimeHunter (talk) 18:03, 9 September 2024 (UTC)

I had noticed it in other places, but I got bothered enough yesterday to report it after my most recent occurrence, which happened to be the series overview template. It also happens to every table in Historical rankings of presidents of the United States, for example. ~Anachronist (talk) 20:21, 9 September 2024 (UTC)

Tech News: 2024-37

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

Feature news

• Starting this week, the standard syntax highlighter will receive new colors that make them compatible in dark mode. This is the first of many changes to come as part of a major upgrade to syntax highlighting. You can learn more about what's to come on the help page. [7][8]
• Editors of wikis using Wikidata will now be notified of only relevant Wikidata changes in their watchlist. This is because the Lua functions entity:getSitelink() and mw.wikibase.getSitelink(qid) will have their logic unified for tracking different aspects of sitelinks to reduce junk notifications from inconsistent sitelinks tracking. [9]

Project updates

• Users of all Wikis will have access to Wikimedia sites as read-only for a few minutes on September 25, starting at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [10]
• Contributors of 11 Wikipedias, including English will have a new MOS namespace added to their Wikipedias. This improvement ensures that links beginning with MOS: (usually shortcuts to the Manual of Style) are not broken by Mooré Wikipedia (language code mos). [11]

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

MediaWiki message delivery 18:48, 9 September 2024 (UTC)

Deployment of the MOS namespace on English Wikipedia is expected to happen tomorrow. I'll post a list of titles that need to be cleaned up after it happens; expected the bare MOS: and MoS: etc to break; please replace these with WP:MOS. C. Scott Ananian (WMF) (talk) 14:52, 11 September 2024 (UTC)

Enhanced editnotice loader

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)

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)

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)

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)

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)

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)

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)

Font size change in Vector 2010

Tracked in Phabricator
Task T367643

Can anyone have a look at phab:T367643, please? I submitted this task almost four months ago. Thanks, ‑‑Neveselbert (talk · contribs · email) 22:02, 9 September 2024 (UTC)

You are running into Apple's browser's inflation algorithm which is adjusting your font size to what it thinks is the preferred minimum font size because they consider the current font-size too small for the current page and your preferences. It's best to set your preferred font size locally on your device so it doesn't change again.

You can alter this by changing your font size on your device or if you have an account applying text-size-adjust in your user CSS.

html {
  --webkit-text-size-adjust: none !important;
  text-size-adjust: none !important;
}

🐸 Jdlrobson (talk) 00:42, 10 September 2024 (UTC)

@Jdlrobson: thanks for responding. I've tried something like this already, by having JavaScript revert the viewport back to width=100 (reverting the font size back to normal). What I don't understand is why this change was applied to legacy Vector, instead of just the new Vector. ‑‑Neveselbert (talk · contribs · email) 18:59, 10 September 2024 (UTC)

Gallery issue

I noticed some recent gallery's in articles that have this heading: <gallery mode=packed heights=250px>. The result is such a gallery having very big images, not the specified 250px but 469px high. I found the 469px by making a screenshot of the page (using Edge as browser, with zoom 100%), followed by cropping is to contain one image only. For an example see Wat Ket Karam. FredTC (talk) 11:14, 10 September 2024 (UTC)

According to dev tools they are 501x375 — Qwerfjkltalk 17:09, 10 September 2024 (UTC)

The thumbnails are shown too big, because the parameter is not "heights" but "height". "<gallery mode=packed height=250px>" works fine.--Snævar (talk) 22:30, 10 September 2024 (UTC)

No, "heights" is correct. "height" is ignored as an unknown parameter and you get a default size. I don't know the precise algorithm when heights is used but it looks like the browser may calculate how many images will fit in a row with the current window width, and then enlarges the images so the whole window width is used, except it's limited how much it will enlarge an image. And MediaWiki apparently offers a larger image file than requested with the heights parameter so the browser has a good image to work with if enlargement is needed by the algorithm. PrimeHunter (talk) 00:01, 11 September 2024 (UTC)

Then this text:

heights= Image heights in pixels (has no effect if mode is set to slideshow)

in Help:Gallery tag is incorrect. Should the help-info be modified to explain what really happens? --FredTC (talk) 10:58, 11 September 2024 (UTC)

I tried to guess what happens from some tests but I'm not comfortable writing documentation based on that. Help:Gallery tag#Usage notes says:

• The packed mode will automatically adjust image sizes to use available display space optimally.

Help:Gallery tag#packed says: "It may relatively enlarge some images that were smaller in the above views."

The potential enlargement should maybe be mentioned when packed is introduced in Help:Gallery tag#Attributes and values. PrimeHunter (talk) 11:54, 11 September 2024 (UTC)

"Missing in" added to language selector with delay, disrupting the UI

Tracked in Phabricator
Task T344028

Hi,

Whenever I click on the language selector, it shows not only languages in which the article is available, but also suggestions of new languages to translate it in. (Which are never useful to me, but that is beside the point.)

The problem is that this suggestion appears with a delay of a second or so. See screencast:

Typically, I move my mouse cursor to the language name that I want to select, then just before I have the time to click, this suggestion appears and moves the target, so I end up clicking on the wrong languages.

Firefox 129.0 on Fedora 40. EDIT: Also reproduced with Google Chrome. Jean Abou Samra (talk) 13:02, 10 September 2024 (UTC)

This appears to be an issue with the mw:Content translation beta feature, we can not fix this directly here on the English Wikipedia. You could bring this up at the feature talk here: mw:Talk:Content translation and/or open a bug on that feature. If you open a bug, please let us know your bug id so if others come upon this discussion they can follow up on it. — xaosflux ^Talk 13:26, 10 September 2024 (UTC)

Done, thanks. https://phabricator.wikimedia.org/T374449 Jean Abou Samra (talk) 13:49, 10 September 2024 (UTC)

@Jean Abou Samra: If you never use the Content Translation tool then you can disable it at Special:Preferences#mw-prefsection-betafeatures. If you still want the tool enabled but never want the "Missing in [languages]" message then you can add this to your CSS:

.cx-uls-relevant-languages-banner {display:none !important;}

PrimeHunter (talk) 15:15, 10 September 2024 (UTC)

Thanks! TIL I can edit my own CSS directly in Wikipedia (rather than Greasemonkey or similar); this is going to be useful! Jean Abou Samra (talk) 19:07, 10 September 2024 (UTC)

How to mark Minor Edit on Source Editor of Mobile website

Tracked in Phabricator
Task T123694

I want to mark some of my edit as Minor Edit, but unable to do so with source editor. only Visual Editor provide interface to do that but i mostly work with source editor. how to mark any edit as minor edit on source editor of mobile website.

• Browser: Google Chrome 128.0.6613.127

-- kemel49^{(connect)(contri)} 15:19, 10 September 2024 (UTC)

• This feature is not currently available in the mobile web view, see phab:T123694. As a workaround you could change to the desktop view. — xaosflux ^Talk 15:41, 10 September 2024 (UTC)

  @Xaosflux@KEmel49 we have also fielded a couple wishes on this. There might be an update regarding the availability of this feature.

  Out of curiosity, how would you feel if all editors saw this UX? JWheeler-WMF (talk) 19:03, 10 September 2024 (UTC)

  I'd be fine, as they do in VE mode already - think it should at least be consistent. — xaosflux ^Talk 21:47, 10 September 2024 (UTC)

  @JWheeler-WMF: As someone who uses the mobile source editor, I would appreciate the change. I don't think it makes sense to keep it from only one type of editor. QuicoleJR (talk) 12:12, 11 September 2024 (UTC)

• As we note any Minor copy edit as CE at Edit summary field, can't we note any minor edit as <m> or with any other tag,that cannot be marked on checkbox for technical limitation.-- kemel49^{(connect)(contri)} 15:28, 11 September 2024 (UTC)

Cannot watch or mark edit as minor with source editor on mobile website

Buttons for watching or marking an edit as minor are nonexistent on mobile website source editor.

I tested the issue on both Safari 15.6, iPadOS 15.8 on an iPad Mini 4 and on Firefox 129, Android 14 on a Samsung Galaxy S23.

Hopefully this is enough info. Treetop-64bit (talk) 23:24, 10 September 2024 (UTC)

See above section. — xaosflux ^Talk 10:03, 11 September 2024 (UTC)

Why can't I extract the dump?

I tried enwiki-20240820-pages-articles.xml.bz2 and the latest enwiki dump but 7zip and bzip2 keep failing. I redownloaded it multiple times. I'm on Pop OS and there is plenty of disk space available of course.

I am using 7z x enwiki-20240820-pages-articles.xml.bz2 and

bzip2 -d enwiki-20240820-pages-articles.xml.bz2 to extract.

Error messages like ERROR: E_FAIL Archives with Errors: 1 are not very helpful. Polygnotus (talk) 22:33, 10 September 2024 (UTC)

The mailing list may be your best resource for help with that, see meta:Data dumps "Getting help" section for info. — xaosflux ^Talk 23:07, 10 September 2024 (UTC)

Thanks. So far I figured out that the problem is in all tools that use libbzip2 under the hood (I think 7zip and pbzip2 and bzip2). The problem is that the default block size is 900.000 bytes, and if you go over that you get:

pbzip2 -dkv enwiki-latest-pages-articles.xml.bz2 

Parallel BZIP2 v1.1.13 [Dec 18, 2015]
By: Jeff Gilchrist [http://compression.ca]
Major contributions: Yavor Nikolov [http://javornikolov.wordpress.com]
Uses libbzip2 by Julian Seward

         # CPUs: 20
 Maximum Memory: 100 MB
 Ignore Trailing Garbage: off
-------------------------------------------
         File #: 1 of 1
     Input Name: enwiki-latest-pages-articles.xml.bz2
    Output Name: enwiki-latest-pages-articles.xml

 BWT Block Size: 900k
     Input Size: 22880311372 bytes
Decompressing data...
pbzip2: *ERROR: Could not write 900000 bytes to file [ret=-1]!  Aborting...
pbzip2: *ERROR: system call failed with errno=[2: No such file or directory]!
pbzip2: *ERROR: system call failed with errno=[5: Input/output error]!
Terminator thread: premature exit requested - quitting...
Cleanup unfinished work [Outfile: enwiki-latest-pages-articles.xml]...
Deleting output file: enwiki-latest-pages-articles.xml, if it exists...
pbzip2:  *INFO: Deletion of output file succeeded.

SO recommends some .NET lib or provides no answer.

I'll give it a try with Python before I use the mailinglist. Polygnotus (talk) 09:03, 11 September 2024 (UTC)

Notification stoppage after bot edits

Tracked in Phabricator
Task T374404

When a bot edits a watched page or file, notification emails for subsequent human edits stop being sent. Notifications only resume once the page is manually viewed or the entire watchlist is marked as read. Has anyone not had this problem? ‑‑Neveselbert (talk · contribs · email) 19:11, 10 September 2024 (UTC)

Primefac has also highlighted this problem in phab:T358087. It's still a problem, and I've missed dozens of edits because some bot edited a bunch of pages on my watchlist. ‑‑Neveselbert (talk · contribs · email) 19:15, 10 September 2024 (UTC)

See this tool and this discussion for more information. It doesn't get 100% of bot edits but it is about 99% accurate. Primefac (talk) 20:07, 10 September 2024 (UTC)

Thanks Primefac, but how do I get a "Watchlist token"? ‑‑Neveselbert (talk · contribs · email) 21:13, 10 September 2024 (UTC)

@Neveselbert: Special:Preferences#mw-prefsection-watchlist Polygnotus (talk) 21:15, 10 September 2024 (UTC)

Navboxes in mobile view

I'm not sure if this is the right place, but why are navboxes not visible in mainspace articles in mobile view (unless rotated sideways)? They are visible in drafts. Kailash29792 (talk) 01:38, 11 September 2024 (UTC)

phab:T124168 has some background, particularly phab:T124168#1948388. Izno (talk) 01:54, 11 September 2024 (UTC)

Categories with pages that aren't in that cat

Category:NA-Class medicine articles contains a short list of pages. However, if you click on the pages in the cat, e.g., Talk:2024 United States listeriosis outbreak, there is no sign of the cat on those pages. It's been almost 8 weeks since anyone edited that talk page. How do I get this page out of that cat? WhatamIdoing (talk) 01:55, 11 September 2024 (UTC)

Make a null edit of the page. I did and it disappeared from the category. PrimeHunter (talk) 02:04, 11 September 2024 (UTC)

Thanks, that's working on most of them. WhatamIdoing (talk) 02:37, 11 September 2024 (UTC)

Dark mode problems for code blocks

Template:Linux layers is working fine in light mode, but in dark mode, the <code>...</code> blocks (with text like "fopen") are unreadable dark gray text on dark gray background. It looks like that's happening from this CSS block:

@media screen {
  html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) [bgcolor] a:not(.mw-selflink), html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) th[style*="background"]:not([style*="transparent"]):not([style*="inherit"]) a:not(.mw-selflink), html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) td[style*="background"]:not([style*="transparent"]):not([style*="inherit"]) a:not(.mw-selflink), html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) tr[style*="background"]:not([style*="transparent"]):not([style*="inherit"]) td a:not(.mw-selflink) {
    color: var(--color-base-fixed,#202122);

Firefox is telling me it's the last item in the comma-separated list which is active. I think this might be coming from the built-in skin CSS? This is a complicated case because the surrounding background colors are pastel in both light and dark modes, but the background of the code tag itself is white in light mode and dark gray in dark mode. It would require careful testing if this is in fact a skin problem. -- Beland (talk) 03:37, 11 September 2024 (UTC)

Yes, that's a skin issue. @Jon (WMF) Izno (talk) 03:41, 11 September 2024 (UTC)

We can use TemplateStyles here to fix the local case, but links inside <code> is an unanticipated edge case. Izno (talk) 03:42, 11 September 2024 (UTC)

Unicode block template

Not sure where else to properly propose or showcase this, but I did a refactor of the Unicode block template design, introducing various BCP bells and whistles—namely dark mode support via TemplateStyles (Template:Unicode chart/styles minimal.css). Sadly, I can't use <tfoot>. Compare {{Unicode chart CJK Radicals Supplement}}

CJK Radicals Supplement[1][2] Official Unicode Consortium code chart (PDF)

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

U+2E8x

⺀

⺁

⺂

⺃

⺄

⺅

⺆

⺇

⺈

⺉

⺊

⺋

⺌

⺍

⺎

⺏

U+2E9x

⺐

⺑

⺒

⺓

⺔

⺕

⺖

⺗

⺘

⺙

⺛

⺜

⺝

⺞

⺟

U+2EAx

⺠

⺡

⺢

⺣

⺤

⺥

⺦

⺧

⺨

⺩

⺪

⺫

⺬

⺭

⺮

⺯

U+2EBx

⺰

⺱

⺲

⺳

⺴

⺵

⺶

⺷

⺸

⺹

⺺

⺻

⺼

⺽

⺾

⺿

U+2ECx

⻀

⻁

⻂

⻃

⻄

⻅

⻆

⻇

⻈

⻉

⻊

⻋

⻌

⻍

⻎

⻏

U+2EDx

⻐

⻑

⻒

⻓

⻔

⻕

⻖

⻗

⻘

⻙

⻚

⻛

⻜

⻝

⻞

⻟

U+2EEx

⻠

⻡

⻢

⻣

⻤

⻥

⻦

⻧

⻨

⻩

⻪

⻫

⻬

⻭

⻮

⻯

U+2EFx

⻰

⻱

⻲

⻳

Notes 1.^ As of Unicode version 15.1 2.^ Grey areas indicate non-assigned code points

with {{User:Remsense/Unicode chart CJK Radicals Supplement}}

CJK Radicals Supplement

	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
U+2E8x	⺀	⺁	⺂	⺃	⺄	⺅	⺆	⺇	⺈	⺉	⺊	⺋	⺌	⺍	⺎	⺏
U+2E9x	⺐	⺑	⺒	⺓	⺔	⺕	⺖	⺗	⺘	⺙		⺛	⺜	⺝	⺞	⺟
U+2EAx	⺠	⺡	⺢	⺣	⺤	⺥	⺦	⺧	⺨	⺩	⺪	⺫	⺬	⺭	⺮	⺯
U+2EBx	⺰	⺱	⺲	⺳	⺴	⺵	⺶	⺷	⺸	⺹	⺺	⺻	⺼	⺽	⺾	⺿
U+2ECx	⻀	⻁	⻂	⻃	⻄	⻅	⻆	⻇	⻈	⻉	⻊	⻋	⻌	⻍	⻎	⻏
U+2EDx	⻐	⻑	⻒	⻓	⻔	⻕	⻖	⻗	⻘	⻙	⻚	⻛	⻜	⻝	⻞	⻟
U+2EEx	⻠	⻡	⻢	⻣	⻤	⻥	⻦	⻧	⻨	⻩	⻪	⻫	⻬	⻭	⻮	⻯
U+2EFx	⻰	⻱	⻲	⻳

As of Unicode version 16.0. Grey areas indicate non-assigned code points.

Thoughts? Remsense ‥ 论 07:51, 11 September 2024 (UTC)

@Gonnym suggested the bare EL be converted into a reference. I think I agree with that, but I didn't want to unilaterally change everything at once. It's a pretty dated design though, while several editors have tried to redesign it but haven't completed it. So, I guess I wanted to triage it and do everything right while keeping the manual work of fixing every block manageable. Remsense ‥ 论 15:37, 11 September 2024 (UTC)

A nitpick: I don't love the use of two different fonts and font sizes for the column and row headers, especially since both appear to be different from the base page font. Is there a reason for these fonts to be different from the base page font? See MOS:FONTFAMILY for a guideline. – Jonesey95 (talk) 17:09, 11 September 2024 (UTC)

Thanks for the nitpick, of course! I wouldn't do it purely for decoration per guidelines and good sense; I could easily lose one of the font sizes which was just mirroring the original, but the monospace is due to it being a computer-based code point, I guess? Now that I'm interrogating that again, it's a rather weak reason to insist on it, I think I can 86 that too. Remsense ‥ 论 17:13, 11 September 2024 (UTC)

I do think the table footer is a bit visually distracting at 1rem, especially if the string appears several times on a page corresponding to several blocks. What do you think? Remsense ‥ 论 17:19, 11 September 2024 (UTC)

Can convert it to a {{efn}} note maybe. Gonnym (talk) 17:34, 11 September 2024 (UTC)

Hmm—I think what will work is visually (but not semantically) folding it into the table like in the original. Remsense ‥ 论 17:36, 11 September 2024 (UTC)

Iterated as such. Remsense ‥ 论 17:54, 11 September 2024 (UTC)

Definitely restore the normal-sized and fixed-pitch row and column headers (you might try making *all* the characters normal-sized). Try to make the cells perfectly square and as small as possible, they seem to not be square and are bigger than before. I would just put the text "Unicode 16.0" in the header with a ref leading to the PDF, and also there is no need to tell them that gray cells are unassigned, so both footnotes are removed. Spitzak (talk) 18:22, 11 September 2024 (UTC)

I'm not sure about making square cells—which would be easy to do—of course we inspect isolated glyphs in an ideal square, but I think this becomes significantly harder to read as a table that way. Though, I realize I've picked a CJK block to test this with, maybe that's different with a graphetically different script so square cells would be best.Remsense ‥ 论 18:26, 11 September 2024 (UTC)

Hmm no, I'm full of it and square cells is obviously the move. I've allowed the headers to be bolded like in other tables instead, and I think that's good. Trying to step away so people can analyze for now. Remsense ‥ 论 18:35, 11 September 2024 (UTC)

References

Cleaning up MOS: links

Tracked in Phabricator
Task T363538

With the impending addition of MOS as a namespace on English Wikipedia, [[MOS:]] links (and [[MoS:]] etc) need to be replaced with [[WP:MOS]]. Can anyone help with that cleanup before the MOS namespace rolls out tomorrow? See T363538 and the Tech News item above for more details. C. Scott Ananian (WMF) (talk) 14:56, 11 September 2024 (UTC)

@CAnanian (WMF) wasn't the point of this supposed to be not have to touch 2000+ pages?? Why would we even want a new namespace added here otherwise?? — xaosflux ^Talk 15:27, 11 September 2024 (UTC)

Special:PrefixIndex/MOS:, Special:PrefixIndex/Mos:, Special:PrefixIndex/MoS:. — xaosflux ^Talk 15:29, 11 September 2024 (UTC)

And more specifically to not have to touch every link to these pages on every other page. — xaosflux ^Talk 15:29, 11 September 2024 (UTC)

The request is to fix wikilinks which only say [[MOS:]] (or other capitalizations) without anything after the colon. Those links will become broken like [[Wikipedia:]] which produces [[Wikipedia:]]. It can be fixed by replacing the links with [[WP:MOS]] which produces WP:MOS. A linksto search currently finds 4908 links to MOS: so it sounds like a job for a bot or patient AWB users. PrimeHunter (talk) 15:43, 11 September 2024 (UTC)

Thank you for the clarification. Some of these prob don't need to be done (like old talk archives). — xaosflux ^Talk 16:21, 11 September 2024 (UTC)

Most of them came from {{GAProgress}}, which Stjn already fixed. insource search shows 597 pages still to fix, most of which are old talk archives. * Pppery * _{it has begun...} 16:36, 11 September 2024 (UTC)

I've also filed phab:T374555, since this concept should be supported even though it currently isn't. * Pppery * _{it has begun...} 16:36, 11 September 2024 (UTC)

It’s still many, many pages due to that template being substituted in every GA review. So PrimeHunter’s link is better (since it captures most of the cases which are boilerplate [[MoS:|…]], and your link doesn’t). stjn 16:40, 11 September 2024 (UTC)

True. * Pppery * _{it has begun...} 16:52, 11 September 2024 (UTC)

Old archived pages are routinely cleaned up after changes like this. Please include them in the AWB/bot work. – Jonesey95 (talk) 17:11, 11 September 2024 (UTC)

I'm in principle willing to run a bot to fix this. But I'd like to see what happens with T374555 first. * Pppery * _{it has begun...} 17:12, 11 September 2024 (UTC)

I have just done it. I have skipped user talk pages and just a handful of sandbox pages, for which a bot may be better to avoid OBODs.

I find it telling that of the 500 some odd links, the vast majority were added because of the one template being substed or transcluded. I think maybe only some 100 uses were actual natural links, and those across the time-space of 20 years... well, I wouldn't support the work of that task. There are better edge cases to support. Izno (talk) 17:51, 11 September 2024 (UTC)

Some links start with MOS:#.[12] PrimeHunter (talk) 18:24, 11 September 2024 (UTC)

Filed a related edit request at MediaWiki talk:Title-invalid-empty. * Pppery * _{it has begun...} 16:52, 11 September 2024 (UTC)

Cite links are broken when VisualEditor is rendered in Parsoid

An odd bug that for some reason only affects, ironically enough, the article VisualEditor, which is why Parsoid began in the first place.

For some reason, all citation links, which should normally cause the query fragment of the citation ID to be used as a hyperlink, for example #cite-note_24 in the Technical section, instead get #Technical, the name of a subsection, prepended to them (so something like #Technical#cite-note_24) This naturally is an invalid ID for any element on the page, and thus citations aren't able to send you to where they're stored. Despite the name, this bug appears to affect every citation on the page, as well as the caret links back.

A quick search for another article with a level 3 header as Technical was, Oura Health, did not provoke this bug.

I do apologise if this isn't the right venue for such a technical issue, but I suspect that something on VisualEditor is responsible for making Parsoid act up. Thanks for reading. Regards, User:TheDragonFire300. (Contact me | Contributions). 15:32, 11 September 2024 (UTC)