Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VP(T))
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.

[edit]

My Edit records link, no longer functions properly. GoodDay (talk) 13:36, 4 February 2025 (UTC)[reply]

Is that an old link? The url should look like this https://xtools.wmcloud.org/ec/en.wikipedia.org/X201. Alternatively, go to the bottom of your Contributions page and click Edit Count. - X201 (talk) 14:23, 4 February 2025 (UTC)[reply]
I was required to sign in but after that your link worked. There was a warning on replication lag, which could be causing issues. -- LCU ActivelyDisinterested «@» °∆t° 19:41, 4 February 2025 (UTC)[reply]
Tried again @X201: & @ActivelyDisinterested:, by updating to [1], still won't work. It keeps telling me to log in to continue. GoodDay (talk) 01:31, 10 February 2025 (UTC)[reply]

2022 FIBA Under-18 Women's Asian Championship

[edit]

I would like to report some strange things happening with this article: 2022 FIBA Under-18 Women's Asian Championship. I wanted to move that page to 2022 FIBA U18 Women's Asian Championship (official tournament name as used by FIBA) but I hadn't permission to do so. There is also a draft redirect (Draft:2022 FIBA Under-18 Women's Asian Championship), which does not redirect to this article, but to FIBA Under-18 Women's Asia Cup. I don't know what to think about it. Could some specialist fix it? Thanks in advance. Maiō T. (talk) 20:30, 6 February 2025 (UTC)[reply]

@Maiō T.: In my opinion, I believe that Under-18=U18, U18 is the nickname only. I don't think it's a right decision to move the page. Thanks. Stevencocoboy (talk) 02:21, 7 February 2025 (UTC)[reply]
No, Steven. I've been working with youth championships for some time and since 2017, all continental championships have used an official name without the word "under". See the following examples:
So my goal is to unify the names of all basketball championships since 2017. Maiō T. (talk) 12:07, 7 February 2025 (UTC)[reply]
I have moved the article for you — Martin (MSGJ · talk) 12:28, 7 February 2025 (UTC)[reply]
Thank you Martin. Maiō T. (talk) 13:54, 7 February 2025 (UTC)[reply]
@Maiō T.: I know what you have done. But I don't think it's any difference between of them. If the event title is change, like Asian Championship change to Asia Cup, I suggest your propose. But Under18 change to U18, it isn't any different because 'U' is the nickname only and the meaning is 'under'. Both of them can acceptable. For me it's unnecessary move the page. I'm worried about you may perseverance in here and have a little bit obsessive-compulsive disorder. Thanks. Stevencocoboy (talk) 02:38, 8 February 2025 (UTC)[reply]
[edit]

In HMS Warspite (03) are lots of references formatted <ref>[[#refBallantyne2013|Ballantyne, 2013]], p. 29.</ref and similar. They produce blue-linked "Ballantyne 2013" in the reflist, but clicking on it does nothing. Is there an obvious fix? I've never used the #ref thing, and rarely seen it. Thank you, DuncanHill (talk) 23:56, 6 February 2025 (UTC)[reply]

That's just a manual WP:ANCHOR. I've never seen this citation style 173.206.40.108 (talk) 00:04, 7 February 2025 (UTC)[reply]
Remove ref from Ballantyne, 2013 → Ballantyne, 2013. You could switch to {{sfn}} or {{harvnb}} but that requires modification of the target long-form citation templates (remove |ref=...).
—Trappist the monk (talk) 00:08, 7 February 2025 (UTC)[reply]
It's a citation style that's been used, by as far as I can tell, a minority of hardcore anti-template purists. It's an absolute blight, and those anchors are often broken the vast majority of the time. I personally convert them to proper {{sfn}}/{{harvnb}}-like templates when I can. It's never been an issue. Headbomb {t · c · p · b} 00:13, 7 February 2025 (UTC)[reply]
@Trappist the monk: thank you, it worked, and @Headbomb: it's tempting, much as I loathe sfn it's nowhere near as horrible as this hashed-up hashtag malarky. DuncanHill (talk) 00:39, 7 February 2025 (UTC)[reply]
Template:Ref and Template:Note support anchor links starting with ref, although they look ancient. Snævar (talk) 01:54, 7 February 2025 (UTC)[reply]
They are ancient, see Wikipedia:Footnote3 which was marked "historical" way back in 2009. As for "hashed-up hashtag malarky", it's not "hashed up", the hash character has been the standard way of linking to an anchor since 1992, possibly earlier. It certainly predates Wikipedia, so is not something we invented (unlike, say. the use of double square brackets to make a link). --Redrose64 🌹 (talk) 21:38, 7 February 2025 (UTC)[reply]
"It's an absolute blight..." I couldn't agree more. -- LCU ActivelyDisinterested «@» °∆t° 20:35, 7 February 2025 (UTC)[reply]
  • I agree with Headbomb, and I've never understood the thinking that has 
    <ref>[[#refBallantyne2013|Ballantyne, 2013]], p.&nbsp;29.</ref>
    as somehow easier to write (when it is in fact, as we can see, far more difficult to write, to write correctly, and to maintain — I could do it, but then I understand HTML; when the point of wikitext is that it does not necessitate expansive understanding of HTML for writers who are not like me.) than 
    {{sfn|Ballantyne|2013|p=29}}
    which is only a few vertical bars, an "sfn", and some different brackets from the 
    (Ballantyne 2013 p.29)
    that one would write in an old-style paper article anyway. Indeed, whem someone from the paper world comes along writing the third, converting it to the second shows up as just a few punctuation changes in the diff, because all of the authors, years, and pages (and even the "p"s and "pp"s) match; making it easy to see that one has not messed up the conversion from paper writing to wikitext writing. Uncle G (talk) 06:15, 8 February 2025 (UTC)[reply]
    • The only reason for this "no templates purism" went away years ago. A proliferation of these templates used to really bog down the rendering of a page and stress the servers, and even exceed limits on template expansions on lengthy articles. Then we converted to LUA modules for this stuff, and it sped up by a huge amount and stopped coming anywhere near the limits. It was a very great difference, and any thinking that these templates should be avoided because they are expensive in large numbers went away after I created the LUA versions which is approaching a decade and a half ago now. Uncle G (talk) 06:36, 8 February 2025 (UTC)[reply]

Next steps towards OWID visualization within MediaWiki

[edit]

We at Wiki Project Med have built a method to visualize Our World in Data with all material coming from Commons. You can see it functional at mdwiki:WikiProjectMed:OWID#Way_3_(current_effort).

Wondering if we can get this and this copied to EN WP so we can begin testing here.

On MDWiki you should be able to:

  • scroll through the years of data,
  • if you put your cursor over a country it should highlight and give you the name,
  • if you put your cursor over the ranges bar, it should highlight all the countries in that range,
  • if you click on a country it should pull up a graph of how data has changed in that country over time
  • if you select a region of the world it will zoom into that region

It is built from about 500 seperate images. Doc James (talk · contribs · email) 05:06, 1 February 2025 (UTC)[reply]

We are working on improving functionality on mobile as currently this is poor. Just wanting to begin testing here, it is not ready for us in mainspace. Doc James (talk · contribs · email) 05:15, 1 February 2025 (UTC)[reply]
Notified: WT:GADGET, WP:IANB. –Novem Linguae (talk) 01:14, 7 February 2025 (UTC)[reply]

Technical steps to get this working on enwiki

[edit]

Hey Doc James. What are the exact technical steps to do this? Having these steps would make this more actionable. Are these the steps?

Clicking around the images on the right at https://mdwiki.org/wiki/WikiProjectMed:OWID#Way_3_.28current_effort.29, it looks like this is a gadget to create color-coded world maps, with each country getting its own color depending on the data, that also has a year scale at the bottom, and hovering over each year in the scale changes the data on the world map? –Novem Linguae (talk) 01:13, 7 February 2025 (UTC)[reply]

Yes those would be the next steps.
Basically there are ~13,000 of these graphs under an open license created by Our World in Data.[6] The gadget in question allows one to move through years of the data visualized by heatmap and than click on specific countries to view of graph of how the data changes for that country over time.
What one is doing is moving through images that are stored on Commons. You can see all the individual images here.[7] We used to build these from the underlying data itself but the WMF killed that when they killed graphs. We also build similar functionality in two other ways which were mostly rejected by the WMF.
Doc James (talk · contribs · email) 01:25, 7 February 2025 (UTC)[reply]
Please keep template gadget categories consistent (Category:Pages using gadget xxxxxxxxx). — xaosflux Talk 03:15, 7 February 2025 (UTC)[reply]
Agreed. Doc James, I see the category is currently placed by the module code [8], on lines 48 and 215. Could that be hoisted out so it is placed by the template instead? That'd make it easier to copy paste module updates from mdwiki without messing up the tracking category. –Novem Linguae (talk) 03:20, 7 February 2025 (UTC)[reply]
For sure. Doc James (talk · contribs · email) 04:26, 7 February 2025 (UTC)[reply]

Bug and feature ideas

[edit]

A couple issues that jump out at me in my quick testing, but that may not be blockers, are:

  1. At high browser zooms, when you click on the image, it vertically overflows off the screen, and the vertical scroll bar is scrolled to the bottom by default. I think it'd be more intuitive to have it scrolled to the top by default.
  2. It doesn't appear you can link these rich images in a URL like you can a normal image. That'd be a cool feature to add. I'd like to be able to drop a link here in this discussion to a specific rich image, then the user clicks it and it loads. This is supported for normal files/images in MediaWiki.
  3. The loading 0%, loading 1%, etc. thing at the bottom right of the image takes a long time to load, around 60 seconds, on first load. On second load, it is much quicker. It is unclear what it is loading though. I was able to click around the year slider at the bottom and still have it work, even while it said "loading".

–Novem Linguae (talk) 01:13, 7 February 2025 (UTC)[reply]

  1. Working to fix this I think, can you send an image of what you mean? Are we talking wide or verticle narrow monitors?
  2. Not sure what you mean?
  3. It is loading all the individual images that the tool requires to function. As mentioned the problem with this solution to the issue is that it is data heavy. One of the next steps is to improve load time by only loading the world overview to start with and not the subregions.
Doc James (talk · contribs · email) 01:28, 7 February 2025 (UTC)[reply]
To clarify #2, I mean that if I go to Buff Cobb and click on the first image, the URL changes from https://en.wikipedia.org/wiki/Buff_Cobb to https://en.wikipedia.org/wiki/Buff_Cobb#/media/File:Buff_Cobb_1957.JPG. But if I go to https://mdwiki.org/wiki/WikiProjectMed:OWID#Way_3_.28current_effort.29 and click on the first image, the URL stays the same. I have no way to share the image URL here in a way that will instantly load it. Hope that makes sense. –Novem Linguae (talk) 01:35, 7 February 2025 (UTC)[reply]
Ah sure yes can add that Doc James (talk · contribs · email) 01:57, 7 February 2025 (UTC)[reply]

Consensus

[edit]

Do folks on enwiki want this? To me, it seems a little heavy, but that can be mitigated by making it a mw:Template gadget. Is probably OK to install. Other thoughts? –Novem Linguae (talk) 01:42, 7 February 2025 (UTC)[reply]

Note that we already have ImageStackPopup deployed as a template gadget. Fine with deploying OWID as a template gadget too. * Pppery * it has begun... 02:22, 7 February 2025 (UTC)[reply]
I don't think this extremely long loading time meshes very well with the rest of our pages. — xaosflux Talk 03:17, 7 February 2025 (UTC)[reply]
We are working to improve how fast it works by only loading the bits people click on. Plus this is how fast it works on MDWiki and EN WP is way more powerful. Would be useful to be able to test it here on EN WP to see how fast it is here. Doc James (talk · contribs · email) 03:49, 7 February 2025 (UTC)[reply]
@Doc James: Strong oppose This is like a DDoS attack against enwiki. The first example made 226 requests, which would normally set off firewall alerts seems excessive. Furthermore, it downloaded 35.51 Mb without warning. What about mobile data users?
Here is what should have been done: Just use a c:Category:Interactive SVG. 173.206.40.108 (talk) 11:08, 7 February 2025 (UTC)[reply]
You can do this with an interactive SVG? How?
What are the rules about sizes. COVID19 pandemic is 2.2 Mb. We are looking a decrease the initial load by 6 to 8 fold as mentioned above. Plus this only loads when people want an interactive version.
Loading todays feature picture is 7.7 MB. I imagine we could stipulate how much will be loaded before people progress. Doc James (talk · contribs · email) 11:39, 7 February 2025 (UTC)[reply]
Why not?
  1. scroll through the years of data File:Colonisation2.svg but with the scroll detection from [9]. Basically, interactive SVG can hide/show anything on scroll, click, or hover.
  2. if you put your cursor over a country it should highlight and give you the name Last example of [10] for the tooltips, and the countries in File:Evolution_of_the_European_Union_SMIL.svg for the highlighting
  3. if you put your cursor over the ranges bar, it should highlight all the countries in that range Change click to hover in the timeline above File:Evolution_of_the_European_Union_SMIL.svg
  4. if you click on a country it should pull up a graph of how data has changed in that country over time Same as 1, just change to a new image like in File:SVG feDisplacementMap Demo.svg
  5. if you select a region of the world it will zoom into that region I didn't see this in the first example, but it's the same idea as 4
It would load instantly. Data savings come from using <defs> to not repeat country shapes. 173.206.40.108 (talk) 12:31, 7 February 2025 (UTC)[reply]
Nice thanks. Doc James (talk · contribs · email) 12:52, 7 February 2025 (UTC)[reply]
I was focusing more on load time and request count. But as requested, let's look into sizes: File:Death-rate-by-source-from-indoor-air-pollution,World,1990.svg is 162 KB (Firefox, uncompressed, rounded up). Most of it is country shapes, which don't need to be repeated 226 times. 25% appears to be repeated <span class="attribute-name"> ... <a class="attribute-value"> can't find this, might have incorrectly downloaded, but let's ignore that optimization for simplicity. Interactivity code should be around the same 52 KB as the gadget. 31 years of data is 157 KB (description).
In total, 162 + 52 + 157 = 371 KB. A max of 3 MB should be more than enough. 173.206.40.108 (talk) 13:24, 7 February 2025 (UTC)[reply]
We did not make the svgs but simply downloaded them from OWID. But could definitely look at more efficient processing of them. Doc James (talk · contribs · email) 01:24, 8 February 2025 (UTC)[reply]
would normally set off firewall alerts. Are you speaking generally or do you have knowledge of how WMF's firewalls work? By the way you may want to login if you want us to take you seriously. It's hard to judge your mediawiki technical experience when you are using an IP account. –Novem Linguae (talk) 15:00, 7 February 2025 (UTC)[reply]
alerts hence I was talking about corporate outbound firewalls, not mediawiki.
Looking at mediawiki limits now, they appear to be unlimited or near-unlimited (although the requests weren't to thumb{,_handler}.php, so probably unlimited).
hard to judge It's OK to ignore anything I didn't cite. I'll just strike that part. Aside from the technical details of the potential solution, the rest can be considered to duplicate what Xaosflux and Sohom Datta said. 173.206.40.108 (talk) 15:32, 7 February 2025 (UTC)[reply]
  • Strong oppose - This is not well designed, a few issues immediately popup:
  • Extremely high resource usage - Clicking on the first example loads 56 concurrent requests (amounting to a total of 23.9 MB transferred) for images despite there being no significant interaction with the slider itself. In certain cases, the resources never finish fetching and the loading percentage ticker proceeds extremely slowly (even on my beefy laptop connected to fairly fast campus internet). -- Additionally, if these images haven't been rendered before, this level of resource pre-fetching might be prone to creating a outage on the image rendering backend of Wikipedia (Thumbor)
  • Buttons - After clicking around a bit, I was somehow able to get 4 progressive back buttons to show up on the top of my screen. In certain cases, these buttons would be rendered just outside my viewport making it impossible to navigate using the back button. I also wonder why the "return to article" is a progressive call-to-action as opposed to being a quiet cross on the left side as is customary in the OOUI/Wikimedia design language.
  • Unselectable text - The explanation given under the pictures cannot be selected or highighted/copied normally without having to select the whole page. The read-more link doesn't appear to work as well.

The second and third issues are potentially fixable, the first being the reason, I'll be strongly opposing this request. Sohom (talk) 12:40, 7 February 2025 (UTC)[reply]

Yah per the starting comments "Just wanting to begin testing here, it is not ready for us in mainspace" Doc James (talk · contribs · email) 12:58, 7 February 2025 (UTC)[reply]
@Doc James I guess then my question would be along the lines of "why on enwiki"? -- What feature on enwiki do you plan to test against? Sohom (talk) 14:00, 7 February 2025 (UTC)[reply]
How fast it works for one Doc James (talk · contribs · email) 00:59, 8 February 2025 (UTC)[reply]
Strong oppose For two reasons:
  • Firing this sheer number of requests is really unsustainable honestly, as well as having to upload 100s to 1000s of SVGs for every single graph state.
  • Security vulnerabilities: One of the reasons we don't allow inline rendering of SVGs in MediaWiki is because it is a potential XSS vector. This gadget bypasses this and now as soon as someone finds an SVG XSS filter evasion in MediaWiki, they can run JavaScript on the victims computer when they open the graph, simply by uploading the vulnerable SVG to the Commons image for the default year.
I appreciate the effort of MDWiki for trying to utilize the OWID graphs, however I don't think this is the way to do it.
Dylsss(talk contribs) 19:15, 7 February 2025 (UTC)[reply]
We have a tool that does the batch uploads. So not an issue. We could load images as people request/move through the content to decrease requests. Not sure how it will effect functionality. We were looking at just using https://m.mediawiki.org/wiki/Extension:ImageMap as built by User:Tim Starling. Not sure if that would solve the security concerns. Doc James (talk · contribs · email) 01:38, 8 February 2025 (UTC)[reply]
Also do we not run appropriate sanitisation of svg uploads to Commons to prevent this? Doc James (talk · contribs · email) 02:03, 8 February 2025 (UTC)[reply]
Okay confirmed with someone who was on the security team that svgs are indeed sanitized on upload. And thus one should not be able to replace one we use with a malicious one as outlined. Doc James (talk · contribs · email) 02:29, 8 February 2025 (UTC)[reply]

(Still) getting semi-logged out.

[edit]

By "semi" I mean I only have to click "log in" to get back in, not fill in my password or anything. But still annoying to have Vector2022 constantly flash onto my screen and have to log in in a separate tab so my IP address isn't logged. I'm on Firefox on a Mac. This seems to come in waves: it's bad for a few days and then mostly seems to go away, and then comes back. Cremastra (talk) 21:28, 7 February 2025 (UTC)[reply]

This is happening nearly once every three minutes, I swear. Cremastra (talk) 22:08, 7 February 2025 (UTC)[reply]
I think screen recording your circumstances will explain the problem better. ✠ SunDawn ✠ (contact) 12:16, 8 February 2025 (UTC)[reply]
Thanks, once it starts happening today I'll try to get a recording. Cremastra (talk) 14:26, 8 February 2025 (UTC)[reply]
Here it is:
  1. Logged in in "edit mode" on an article.
  2. 0:06–0:09: I refresh the page.
  3. 0:10–0:15: switch to reading mode. Still looks as if I'm not logged in.
  4. I click the log-in button and my usual view is restored.

Cremastra (talk) 16:10, 8 February 2025 (UTC)[reply]
Make sure you use the "keep me logged in" option when logging in. If that doesn't help, you can try disabling ETP for Wikipedia - the site doesn't contain any actual trackers, but Firefox is probably picking up the central login system as one.
Hopefully the ongoing update of the login system will improve this, although there can be lots of different causes for login issues so it is hard to say. Tgr (WMF) (talk) 13:18, 10 February 2025 (UTC)[reply]
Okay, thanks. Cremastra (talk) 13:22, 10 February 2025 (UTC)[reply]

Are .svg files served to wikipedia directly (not from commons) sanitized?

[edit]

SVG files loaded onto commons are checked for vulnerabilities however weather that is the case for svg uploaded directly onto wikipedia itself is not known. Throwaway 55216 (talk) 11:49, 8 February 2025 (UTC)[reply]

I'd imagine they are checked in the same way, because it's the same software and back end. It would be useful to know exactly what sanitization rules are used: there seems to be some information at https://commons.wikimedia.org/wiki/Help:SVG. The key thing to note here is that Wikipedia only ever serves externally-generated SVG files within pages in a rendered form as a PNG raster file, greatly reducing the possibility for attacks on end user browsers. Hopefully the SVGs are rendered in a suitably secure sandbox environment, on top of the sanitization checks before rendering.
By the way, there's no need to create multiple throwaway accounts, you can just create a single account and stick with it. I've blocked your multiple throwaway accounts, since users are only allowed a single main account, but because you are clearly here for constructive reasons, I've altered your account blocks to enable you to create another account; but please only create a single account, and stick with it. — The Anome (talk) 12:36, 8 February 2025 (UTC)[reply]
https://github.com/wikimedia/mediawiki/blob/master/includes/upload/UploadBase.php#L1621 (it should be noted that this validation uses XML parsing rules not HTML. There are subtle differences between the two which might alter how the SVG is interpreted if it was inserted directly into an html document instead of being rendered standalone) Bawolff (talk) 18:08, 8 February 2025 (UTC)[reply]
Note: the OP has since been blocked, for abusing multiple accounts. Their first mention of this matter seems to have been at Talk:South Africa's genocide case against Israel#.svg link likely containing malware embedded within page, and there have been several other similar posts by this user, so WP:MULTI also applies. --Redrose64 🌹 (talk) 21:31, 8 February 2025 (UTC)[reply]
Ah. I thought this was in the context of #Next steps towards OWID visualization within MediaWiki which is why I mentioned HTML vs XML serialization which might be relevant to that discussion, but isn't to the other one. Bawolff (talk) 23:03, 8 February 2025 (UTC)[reply]
AFAIK, we don't render any user-generated SVG, "sanitized" or otherwise, directly into browsers; that would be a security nightmare. — The Anome (talk) 11:05, 9 February 2025 (UTC)[reply]
Currently, that is correct. We might end up doing it in the future (phab:T5593). Browsers have reasonable sandboxing (no external fonts or javascript) for SVGs included in <img> tags, but some amount of additional sanitizing work in MediaWiki, especially for old files, is probably a good idea. There are likely still some number of pre-sanitization files that may include javascript and/or remote fonts, which currently still run when viewing the source SVG (phab:T117618). Figuring out how to make translation and fonts work consistently is likely a bigger problem. AntiCompositeNumber (talk) 00:21, 12 February 2025 (UTC)[reply]

Petscan dead?

[edit]
Resolved
 – Appears to be up again. — xaosflux Talk 19:26, 10 February 2025 (UTC)[reply]

Wikipedia:PetScan seems not to be running any more. Is this a temporary glitch, or something more serious? It's part of several workflows I'm currently using. — The Anome (talk) 13:08, 8 February 2025 (UTC)[reply]

Try this page. This external volunteer run tool has been having some recurring issues. — xaosflux Talk 20:50, 8 February 2025 (UTC)[reply]

Palestine

[edit]

Once again, Special:WantedCategories is infested with several redlinks caused by the bot-move of a template-generated and template-transcluded category, where the implicated template imports its category generation from a module I can't edit. They all relate entirely to the move of "State of Palestine" categories to the straight unmodified form "Palestine".

There were also three cases where the use of {{YYYY in nationality sport category header}} on a "YYYY in Palestinian sport" category was generating a redlinked "YYYY in the Palestinian territories" category instead of the "YYYY in the State of Palestine" category that already existed in all three cases, where all other categories of the "in the Palestinian territories" form existed as redirects to the "in the State of Palestine" form rather than content categories in their own right — so I accordingly had to create the following three categories as category redirects to the existing form, but they still need to be emptied out in ways I still can't fix myself because module.

But since all of this is module-farmed stuff I can't fix since I don't have module-editing privileges, I need somebody to get these categories cleaned up. Thanks. Bearcat (talk) 16:21, 8 February 2025 (UTC)[reply]

The redirects were already fixed (I think the pages just needed a WP:NULLEDIT). I've fixed all of the remaining ones except "sports", which requires a subcategory to be renamed, which takes two days to process. * Pppery * it has begun... 17:05, 8 February 2025 (UTC)[reply]

TemplateStyles not just for templates anymore

[edit]

 Courtesy link: Help talk:Table/styles.css § Added to table help template surrounded by includeonly tags.

It's clear that CSS style pages invoked using <templatestyles src="ns:Foo/styles.css" /> are no longer limited to the Template and Module namespaces, and some guidance about this would be helpful to editors faced with creation and maintenance of style pages in other namespaces.

A question came up at Help talk:Table/styles.css about whether to use template {{Uses TemplateStyles}} in the header of Help:Table or not, given that Help:Table is not a template. I opined that yes, we should use it, because usage of styles.css has gone well beyond Template and Module space (although the template wording does not currently lend itself well for use in Help space).

Some stats on other namespaces that use TemplateStyles

Namespaces other than Template and Module that use template {{Uses TemplateStyles}}:

Also, pages entitled styles.css are used in other namespaces, even if they are not called out with template {{Uses TemplateStyles}}:

Initially, this raises the issue whether we should write another "Uses" template or perhaps better, just adjust the verbiage "This [template|page|{{{param}}} ] uses...", either automatically via namespace detection or via parameter, and adjust the doc: "This template is used to show that [templates|pages|...] have been converted to use TemplateStyles." Secondarily, is there a guidance page somewhere on use of styles.css pages? If there is, it is not linked from {{Uses TemplateStyles/doc}}.

Given the wider adoption of styles pages beyond template space, maybe it shouldn't have been called TemplateStyles to begin with, but that is 20-20 hindsight, and I realize why it was, and I am not advocating for a change to the TemplateStyles declaration. However, I would like to see help, doc, and project pages aimed at editors stop using the term Template styles exclusively, and replace it with something like, "pages with an accompanying CSS styles page" or the like.

Additionally, some central project or Help page on use of CSS style pages should be created if it doesn't already exist and on that page we should include a section with guidance on what namespaces should, may, should not, and must not use accompanying styles.css pages. For starters, I am assuming that Help, Wikipedia, Portal, their associated talk pages, and Talk may, and probably main and Draft should not (maybe, must not?).

In the meantime, I plan to add {{Uses TemplateStyles}} to Help:Table for now, and possibly come back later and alter the template wording to better handle non-template namespaces, unless there is some objection. Mathglot (talk) 21:16, 8 February 2025 (UTC)[reply]

Listed at: Help talk:Template, WT:WikiProject Templates, Template talk:Uses TemplateStyles. Mathglot (talk) 21:32, 8 February 2025 (UTC)[reply]

VisualEditor can only edit templatestyles transclusions, not add them. That is why I prefer to put templatestyles into templates and then transclude the templates into other namespaces (other namespaces than template and module). Snævar (talk) 22:08, 8 February 2025 (UTC)[reply]
Thanks; good to know about VE limitations, but I am more concerned with the general case involving non-template namespaces, of which there are plenty of examples (see above). Mathglot (talk) 22:18, 8 February 2025 (UTC)[reply]
Wikipedia:TemplateStyles is the guideline on use of templatestyles. If, as with Help:Table, the styles are applied to parts of the page outside of a transclusion (notwithstanding "The style must apply only to the associated template's output"), then I agree it would probably be sensible to include {{Uses TemplateStyles}} or similar either on the page itself (not an article) or its talk page, or to include a note about that in a hidden text comment next to elements in the page where the style is used (if not in close proximity to the templatestyles tag).
I certainly agree that there shouldn't be (and aren't) CSS pages directly in article space (since they aren't articles). If there are legitimate and exceptional reasons for a single article to have extra CSS not attached to a template, then the CSS page should still be in another namespace, like how Main Page has Wikipedia:Main Page/styles.css.
Meanwhile, quite a few article contain the raw wikitext <templatestyles, probably due to subst'ing templates that aren't meant to be substituted. SilverLocust 💬 22:52, 8 February 2025 (UTC)[reply]
In some cases yes. In most other cases the use will be because of trying to dodge issues pertaining to WP:PEIS, where the parent template(s) would otherwise cause a hit to the expansion limit (and such cases should probably have intext comments to be clear that's why they are there). Izno (talk) 00:00, 9 February 2025 (UTC)[reply]
So you created Help:Table/styles.css then added it to Template:Table help, instead of putting it at Template:Table help/styles.css? Much like Scribunto module #invokes, I think in most cases it would be much less confusing for non-technical editors if stuff like that remains wrapped in appropriate templates. Anomie⚔ 14:01, 9 February 2025 (UTC)[reply]
@Anomie: I added it to Template:Table help as a way to instantly be able to use the CSS styles on all table help pages with that template. But if it will work in Template:Table help/styles.css, then that sounds better. Plus then we could use Template:Uses TemplateStyles to link to it from the template.
I would still like a link to the CSS page on all the table help pages, as described by Mathglot. So table editors know where the CSS is coming from, and get more info on it.

This page uses:
Template:Table help/styles.css

Maybe Template:Table help can show the CSS styles link on all pages where it is found. "This page uses..." instead of "This template uses..."
Via includeonly tags to that secondary link box.
--Timeshifter (talk) 16:05, 9 February 2025 (UTC)[reply]

Visual glitch in 2017 wikitext editor

[edit]
Tracked in Phabricator
Task T384908

Hi all, I'm seeing a visual glitch in the wikitext editor as of the last couple of days and the folks at WP:Help desk suggested I post here.

Screenshot of WikiText 2017 editor on Firefox on Mac

Here's a screenshot of the glitch (right, top image) - the green text is not clickable - actually, it appears that it can be edited, but the cursor does not show when clicking inside the green text.

Screenshot of WikiText 2017 editor on Safari on Mac

On Safari (right, second image) the visual glitch is still present though slightly different, once again the green text is editable but the cursor is partially or completely obscured. The top of the cursor only is visible in the screenshot in the web.archive.org URL, the rest of the cursor is cut off.

Any ideas what might be causing this? I tried turning off ad blockers just in case, but it appears to be an unrelated issue. Thanks! Caleb Stanford (talk) 22:35, 8 February 2025 (UTC)[reply]

See phab:T384908. Sjoerd de Bruin (talk) 11:25, 10 February 2025 (UTC)[reply]
@Sjoerddebruin: Ah perfect, many thanks for the reply, glad this is being worked on! Caleb Stanford (talk) 17:16, 10 February 2025 (UTC)[reply]

"Prompt me when entering a blank edit summary" preference does not work on mobile

[edit]
Tracked in Phabricator
Task T232891
Resolved

As far as I can tell, the "Prompt me when entering a blank edit summary" preference does not work in the mobile view. (For example, when I clicked "publish" on this edit without a summary in the mobile view, I wasn't prompted in any way, but when I switched to the desktop view and tried to make another edit without a summary, I got the expected prompt.) Since quite a few users edit Wikipedia on their phones nowadays, I think it would be useful to enable this prompt for mobile views. I guess this will require some software changes and thus a Phabricator task. — Chrisahn (talk) 00:23, 9 February 2025 (UTC)[reply]

[edit]
Resolved

From Nux:"Harvard/Smithsonian/NASA founded institution blocks Wikipedia for whatever reason. If someone can help please see here: Template talk:Minor Planet Center#Links from Wikipedia are blocked."

Setting Wikipedia's Referrer-Policy header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) so visits from Wikipedia cannot be distinguished from other visits may help. Doing this, however, will need (one-liner!) help from WMF Engineering team to set that header to "no-referrer".

It seems entirely reasonable to block the Referer (sic) header via this method, in the interests of reader privacy. Could someone please do this? — The Anome (talk) 08:45, 9 February 2025 (UTC)[reply]

If memory serves, setting up the referrer system we have now was a conscious choice - see eg the discussion at https://phabricator.wikimedia.org/T87276 - so simply turning it off might have unforeseen/undesirable effects. Andrew Gray (talk) 10:10, 9 February 2025 (UTC)[reply]
The previous discussion at Minor planet center actually says this is a European problem, with a user in the US not being affected and several Europeans being affected. If that is true, then changing the referrer is not going to change the Harvard/Smithsonian/NASA block. Snævar (talk) 10:35, 9 February 2025 (UTC)[reply]
I think discussion of the technical details should take place at Template talk:Minor Planet Center#Links from Wikipedia are blocked, not here. Having multiple discussions will increase the confusion. For example, there's a new (12:05) comment by zzuuzz which shows that the problem has to do with the referrer. — Chrisahn (talk) 14:09, 9 February 2025 (UTC)[reply]
I contacted the Minor Planet Center help desk and got a response an hour later (on a Sunday!): "This was a temporary measure. We were being overwhelmed with database requests from Wiki. The situation should be back to normal now." I tried the link and the curl command, both work for me. — Chrisahn (talk) 16:28, 9 February 2025 (UTC)[reply]

TOC numbering in Vector-2022

[edit]

I had the following code on User:CX Zoom/common.css to show numbering on Vector-2022's TOC: 

.vector-feature-zebra-design-disabled .vector-toc .vector-toc-numb {
    display: initial;
    color: black;
    margin-right: 4px;
} /* Vector-2022: display missing numbering on TOC */

But this hasn't been working for quite some time now. What is the fix for it? —CX Zoom[he/him] (let's talk • {C•X}) 10:29, 9 February 2025 (UTC)[reply]

@CX Zoom Elements with the vector-feature-zebra-design-disabled class no longer exist. Try the following instead:
.vector-toc .vector-toc-numb {
    display: initial;
}
Note that the color specification should be dropped to ensure dark-mode compatibility, and while margin-right is optional, I personally don’t think it's necessary. Dragoniez (talk) 13:01, 9 February 2025 (UTC)[reply]
Thanks, this works! —CX Zoom[he/him] (let's talk • {C•X}) 13:21, 9 February 2025 (UTC)[reply]
(edit conflict) @CX Zoom: As far as I am aware, Vector 2022 numbers the TOC entries by default. Perhaps you have some other setting that suppresses the numbering? --Redrose64 🌹 (talk) 13:02, 9 February 2025 (UTC)[reply]
No no, they removed it for some reason. Try logging out and see the TOC. —CX Zoom[he/him] (let's talk • {C•X}) 13:11, 9 February 2025 (UTC)[reply]

reqphotos & maps

[edit]

Is there any way to take articles which are tagged with {{photo requested}} and display them in an interactive map? I've poked around the reqphoto pages, but didn't come across anything. — Fourthords | =Λ= | 19:52, 9 February 2025 (UTC)[reply]

Wiki Loves Monuments does that kind of stuff. Some places in the photo competition have a coordinate, that gets stored in a sql database. That database is then used to show the places on a map.
Sorting pages transcluding "template:photo requested" with locational categories would be orders of magnitude simpler. Snævar (talk) 19:22, 10 February 2025 (UTC)[reply]
Yes. Navigate to the most relevant subcategory in Category:Wikipedia requested photographs by location and use the "Map all coordinates using OpenStreetMap" option. – SD0001 (talk) 09:25, 11 February 2025 (UTC)[reply]

Simple Article Summaries: research so far and next steps

[edit]

The Web team at the Wikimedia Foundation has been working to make the wikis easy to engage and learn from so that readers will continue coming back to our wikis frequently. One of our projects is focused on experimenting with ways to simplify and summarize text. Now, we wanted to share some research results. Soon, we will be asking you how to make it possible for you to moderate a new feature, and how to test it.

Background

This need was also identified as part of the early movement strategy research

For a few years now, the Wikimedia Foundation Research team has been studying test simplification models as part of their program on addressing knowledge gaps.

Some Wikipedia articles are written at a high reading level. For example, according to the Flesch–Kincaid method, the lede of the English article on Dopamine scores at a college graduate level. Meanwhile, the average reading level for adult native English speakers is that of the level of 14–15-year-old students (US 9th grade), and it may be lower for non-native English speakers who regularly read English Wikipedia. The same applies to many other language versions of Wikipedia.

Many readers need some simplified text in addition to the main content. In previous research, we heard that readers wanted to have an option to get a quick overview of a topic prior to jumping into reading the full article.

There are projects that simplify content already, such as Simple English Wikipedia or Basque Txikipedia. However, these are difficult to grow – they are only available in a few languages and ask editors to rewrite content that they have already written, which can feel very repetitive. We wanted to look at ways to make this process easier, by automating summaries.

Summary prototype and testing

In late 2024, we decided to test a feature driven by the findings of this research. We built a prototype that showed summaries generated by the text simplification model at the top of the page. The summaries are made by a model that takes the text of the Wikipedia article and converts it to use simpler language.

We tested this prototype in two ways: qualitatively through user interviews, and quantitatively through a browser extension (which let users interact with the feature in their daily use of Wikipedia).

The prototype received positive results in both tests:

  1. Users are interested in the feature (as measured through initial engagement with summary feature) – Out of all pageviews where summaries were displayed, 8.09% of pageviews had a summary opened. This is a lot – for reference, we can compare to the article recommendations experiment, which received a clickthrough of 0.5% for a feature idea of similar prominence.
  2. Users reported positive experiences (as measured by the answers to the "was this useful?" question) – 75.2% of all clicks selected "yes", 24.8% of all clicks selected "no".

Next steps

We would like to do a wider test as well as discuss ways for editors to contribute or moderate these summaries. We are currently figuring out what this process would look like - potentially starting with something like a gadget or beta feature on interested wikis. We will come back to you over the next couple of weeks with specific questions and would appreciate your participation and help. In the meantime, for anyone who is interested, we encourage you to check out our current documentation.

Thank you! OVasileva (WMF), SGrabarczuk (WMF) (talk) 15:11, 10 February 2025 (UTC)[reply]

Tech News: 2025-07

[edit]

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

Weekly highlight

Updates for editors

  • The "Special pages" portlet link will be moved from the "Toolbox" into the "Navigation" section of the main menu's sidebar by default. This change is because the Toolbox is intended for tools relating to the current page, not tools relating to the site, so the link will be more logically and consistently located. To modify this behavior and update CSS styling, administrators can follow the instructions at T385346. [11]
  • As part of this year's work around improving the ways readers discover content on the wikis, the Web team will be running an experiment with a small number of readers that displays some suggestions for related or interesting articles within the search bar. Please check out the project page for more information.
  • Advanced item Template editors who use TemplateStyles can now customize output for users with specific accessibility needs by using accessibility related media queries (prefers-reduced-motion, prefers-reduced-transparency, prefers-contrast, and forced-colors). Thanks to user Bawolff for these improvements. [12]
  • Recurrent item View all 22 community-submitted tasks that were resolved last week. For example, the global blocks log will now be shown directly on the Special:CentralAuth page, similarly to global locks, to simplify the workflows for stewards. [13]

Updates for technical contributors

  • Wikidata now supports a special language as a "default for all languages" for labels and aliases. This is to avoid excessive duplication of the same information across many languages. If your Wikidata queries use labels, you may need to update them as some existing labels are getting removed. [14]
  • The function getDescription was invoked on every Wiki page read and accounts for ~2.5% of a page's total load time. The calculated value will now be cached, reducing load on Wikimedia servers. [15]
  • As part of the RESTBase deprecation effort, the /page/related endpoint has been blocked as of February 6, 2025, and will be removed soon. This timeline was chosen to align with the deprecation schedules for older Android and iOS versions. The stable alternative is the "morelike" action API in MediaWiki, and a migration example is available. The MediaWiki Interfaces team can be contacted for any questions. [16]

In depth

  • The latest quarterly Language and Internationalization newsletter is available. It includes: Updates about the "Contribute" menu; details on some of the newest language editions of Wikipedia; details on new languages supported by the MediaWiki interface; updates on the Community-defined lists feature; and more.
  • The latest Chart Project newsletter is available. It includes updates on the progress towards bringing better visibility into global charts usage and support for categorizing pages in the Data namespace on Commons.

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

MediaWiki message delivery 00:09, 11 February 2025 (UTC)[reply]

Uptick in non-minor edits being marked as minor

[edit]
Moved from WP:AN § Uptick in non-minor edits being marked as minor

I wasn't sure where to post this, but I noticed there has been a big uptick in new editors marking non-minor edits as minor. This has even included additions or large blocks of text. Is there a reason behind this? TornadoLGS (talk) 22:33, 10 February 2025 (UTC)[reply]

Can someone compile a quick statistic of "percentage of registered users' edits marked as minor" for this month vs., say, the first 10 days of February 2024 and 2023? ~ ToBeFree (talk) 00:56, 11 February 2025 (UTC)[reply]
Here you go. (Though, it turns out a whole lot of those are bots' fault.) —Cryptic 05:55, 11 February 2025 (UTC)[reply]
And here is per-month since Jan '23. I don't see any meaningful trend, either way of looking at it, but between bots, vandalism rollbacks, and massive AWB runs, anything else might get lost in the noise. -- Tamzin[cetacean needed] (they|xe|🤷) 06:40, 11 February 2025 (UTC)[reply]
Thank you very much! 😃
The "uptick" is probably mostly subjective. ~ ToBeFree (talk) 22:46, 11 February 2025 (UTC)[reply]
I was wondering if there was something making it so the "minor edit" checkbox was being checked without an editor meaning to. Like by a script or some default setting. TornadoLGS (talk) 23:35, 11 February 2025 (UTC)[reply]
A possible solution to this, at least a solution I've dwelled upon for a while before this thread was started, is as follows:
The little box saying 'This is a minor edit' could instead do something like what follows: This is a minor edit More info
with the 'more info' popup not opening a new tab, but summarizing what a minor edit is (with the full link, of course) JayCubby 02:20, 11 February 2025 (UTC)[reply]
I had also wondered if an edit filter could work where it gives a gentle message for new users if an edit changes content by more than a certain number of characters. TornadoLGS (talk) 04:52, 11 February 2025 (UTC)[reply]
I've noticed that lately AN hasn't gotten a lot of traffic. You might consider posing your requests at Wikipedia:Village pump (technical) and see if anyone who frequents that board can respond to all of your queries as this seems to involve technical expertise, not adminning expertise. Liz Read! Talk! 05:01, 11 February 2025 (UTC)[reply]
Thank you @Liz:, done now. JayCubby 05:12, 11 February 2025 (UTC)[reply]
No, AbuseFilter will not work. AbuseFilter has a throttle that gets triggered if too high of a percentage of edits get hit with it. This percentage is 5%, so compared to the percentages Cryptic provided, a abuse filter would shut itself down 6-9 times a day, dependant on the month. Snævar (talk) 06:40, 11 February 2025 (UTC)[reply]
Could multiple abuse filters be made to only trigger for certain users, e.g. only IP users, users, autoconfirmed users, extended confirmed users, depending on which filter, and would that maybe solve the 5% problem? The downtime would be lower that way, I assume. Adam Black talk • contribs 06:52, 11 February 2025 (UTC)[reply]
I've been told in the past by people who know more about AbuseFilter than I do that this is a common misunderstanding of throttling. Looking at mw:Extension:AbuseFilter § Emergency throttling, it appears to only apply to recently-edited filters and only prevents blocking and rights removal, neither of which we do on enwiki. I'm also not convinced that "minor edit by a new/unregistered user that changed more than a few bytes" would hit 5% anyways. That said, I'd oppose a filter as overkill. Mislabeling as minor is a relatively, well, minor problem; on the other hand, people abandoning good edits because they got a warning message and they didn't understand how to resubmit the edit or got demoralized, is a very real problem we see all the time. Ultimately, the concept of "minor edit" works on good faith, and if you're not comfortable deferring to your colleagues' self-designation of what's minor, you shouldn't check the boxes that say to trust that. I don't mean that derisively; I've always selected "show minor edits" on my watchlist for this exact reason. -- Tamzin[cetacean needed] (they|xe|🤷) 07:01, 11 February 2025 (UTC)[reply]
Yes, I wasn't clear on why some editors were interested in why or how often editors checked the "minor edit" box but it must have something to do with Watchlist filtering. To me, it seems like an afterthought that I sometimes check off and other times forget to check off. Liz Read! Talk! 07:20, 11 February 2025 (UTC)[reply]
I think we should rename "hide minor edits" to "hide edits marked as 'minor'" to manage expectations better. Most of my minor edits are not marked as minor and I do not care how other people use that box. —Kusma (talk) 07:53, 11 February 2025 (UTC)[reply]
The current wording in the filter dialog is "Minor edits: Edits the author labeled as minor" (MediaWiki:rcfilters-filter-minor-label + MediaWiki:rcfilters-filter-minor-description). -- Tamzin[cetacean needed] (they|xe|🤷) 08:02, 11 February 2025 (UTC)[reply]
Ok, but then I don't see why anyone using that filter is complaining. —Kusma (talk) 08:12, 11 February 2025 (UTC)[reply]
Perhaps just a logging-only filter, if we don't have one already? Large edits marked as minor is a red flag to me and seems worth highlighting for people doing anti-vandalism work. But I was sure we already highlighted that, for just that reason. --Aquillion (talk) 13:00, 11 February 2025 (UTC)[reply]
I started editing again very recently, and the edits were classified as minor by default without me noticing. Interestingly, the edit on this page is not pre-selected as minor, no idea why. Maybe the default is different depending on the language? --Entinator (talk) 19:42, 11 February 2025 (UTC)[reply]
...I don't think there's any reason that 'This is a minor edit' should be ticked by default at all? - The Bushranger One ping only 05:11, 12 February 2025 (UTC)[reply]
We should delete the entire "minor edit" feature. In theory, it has some value. In practice, it's so often ignored, used incorrectly, or just plain intentionally abused, it has long since ceased to be useful. RoySmith (talk) 02:02, 12 February 2025 (UTC)[reply]

Thumbnail background

[edit]

The English Wikipedia used to have white background for thumbnail images with transparency. It was specified explicitly in MediaWiki:Common.css from 2010 until 2017, when that style was removed locally because is was implemented globally (T154077). However, relatively recently that global style for the white background disappeared, so all transparent thumbnails became gray (here and on other Wikipedias as well). I guess that this change was related to introducing the "dark theme" but could not find any explanations why it must result in reducing the contrast in both cases instead of using the appropriate theme-dependent background (white/black, same as the page itself). Does anybody know the story behind this change and whether it was intentional? Is it possible to make specific thumbnails appear "opaque" (having background = page color) without modifying the files? — Mikhail Ryazanov (talk) 22:51, 11 February 2025 (UTC)[reply]

The background for images ended up being 'background-color-interactive-subtle', which is, as you guessed, a dark theme color variable - change 3. That change had two preceding changes - change 1 and change 2.
You could override the style in a similar way english wikipedia did originally in common.css, just add additional declarations to it to make it apply to one image only. Snævar (talk) 23:17, 11 February 2025 (UTC)[reply]
Plain
In {{stack}}
With class=skin-invert
Could you please clarify how to override the background for a specific thumbnail?
The only relevant thing I've found in the documentation is class=skin-invert to allow "inverting" the image colors in the dark mode (technically, apply filter: invert(1) hue-rotate(180deg), which should be equivalent to inverting the luma). This, however, is also problematic because the dark-mode background is inverted with the image, and it actually is redefined to hard-coded value #c8ccd1, which makes the gray line in this example image practically invisible (what is even more weird, when I've tried to place these images inside {{stack}} or {|class="floatright" ..., their backgrounds in the dark mode became very different). This particular image is perhaps not an example of how to make good images but it is kind of illustrative in the sense that many images with transparent background are intended to be displayed over white background (or that the user will choose the background wisely) rather than arbitrary shades of gray. — Mikhail Ryazanov (talk) 07:08, 12 February 2025 (UTC)[reply]
Probably this is something we could ask to change upstream. Izno (talk) 00:14, 12 February 2025 (UTC)[reply]
I also hope so. Would you please take care of this? — Mikhail Ryazanov (talk) 07:08, 12 February 2025 (UTC)[reply]

Random vital articles

[edit]

On the WP:Vital articles pages for each level, there is a random article button on each level as well as each category. Originally, the random article button was for the top-level categories beginning with Category:Wikipedia level-1 vital articles, level 2, level 3, and so on, but the articles are now sorted by article quality and category. I put a temporary solution in to combine multiple categories into one, but I am hoping for a solution that randomizes the vital articles better. I particularly like this feature of vital article for two reasons. Obviously, one is to improve the articles, but I also find it a neat way to read random articles as a reader. Any ideas on how I can do this? Interstellarity (talk) 00:50, 12 February 2025 (UTC)[reply]

As far as I know, this is not possible. Categories can be infinitely deep, so you cannot 'randomly' select something from them. That's why using subcategories is often not a good idea and have multiple categories is better, especially when you are essentially applying labels to something. —TheDJ (talk • contribs) 10:16, 12 February 2025 (UTC)[reply]
It's not a one-button solution and there's a bit of a learning curve, but PetScan can do this. All talk pages descending from Category:Wikipedia level-3 vital articles (depth 2) in random order. —Cryptic 10:45, 12 February 2025 (UTC)[reply]

Black rectangle instead of image

[edit]

The image on Nadín Ospina appears as a solid black rectangle when I view it on my desktop (Edge + Vector Legacy (2010)) If I click on the rectangle it takes me to the image file, which I can see, and I can see it on my phone. I've tried zooming in and out, and rebooting my PC, but it is still a black rectangle. I this a known problem? - Arjayay (talk) 09:49, 12 February 2025 (UTC)[reply]

This happens when the original image has incorrect or missing metadata for the color transform or something. Someone with some skill in image editing, will have to pull that image through an image editor to fix it and upload a new version. —TheDJ (talk • contribs) 10:11, 12 February 2025 (UTC)[reply]

Can't fix duplicate sources

[edit]

SpaceX Starship has a lot of duplicated sources such as Cite error: The named reference "Sesnic-2021" was defined multiple times with different content (see the help page).

However inspecting the code I can't find this duplicate definition (there are multiple such cases in the reflist). What am I missing? Thanks {{u|Gtoffoletto}}  talk 19:05, 12 February 2025 (UTC)[reply]

@Gtoffoletto, SpaceX Starship is transcluding sections from SpaceX Super Heavy and SpaceX Starship (spacecraft) both of which have references with the same names. So, when they appear in the same article, you're getting the cite error message. Nthep (talk) 19:20, 12 February 2025 (UTC)[reply]
thanks! Quick fix is to change the references to something more unique? {{u|Gtoffoletto}}  talk 20:43, 12 February 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1275401883"