This came up in a discussion with some OSM folks, who were asking whether a building's address should also be given as an alias.

@Krinkle wrote on 10 July 2021:

See also EventSource as used by Pywikibot, which has an example of good error handling as part of the loop.

Ref https://github.com/wikimedia/pywikibot/blob/2b8402a66e28ae4be30f74deb9e4e72ac529ef69/pywikibot/comms/eventstreams.py#L288-L303

This broke ImageAnnotator on some Commons file pages: https://commons.wikimedia.org/w/index.php?title=MediaWiki:LAPI.js&diff=prev&oldid=1273254834 https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-ImageAnnotator.js#annotations_with_problems https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#%22Add_a_note%22

In T436505#12270181, @MatthewVernon wrote:

I'm not sure why https://en.wikipedia.org/wiki/File:Warsaw_Pact_in_1990_(orthographic_projection).svg is adding all the query parameters to the image URL...

This is a known incident being actively responded to. https://www.wikimediastatus.net/incidents/9mg9mtxfxpjl

Decline per T40010

This seems to no longer be a problem, presumably due to API changes

Seems like the WMCS deadline for this has snuck up on us a bit.

[06:28:12] AntiComposite: bd808: bah, that was me, was testing it in read-only mode against the new opensearch cluster and forgot to change it back. fixed now

Seems to be working normally now.

ins-502b has been blocked by EasyPrivacy since March 19: https://github.com/easylist/easylist/commit/57fc704de449fcfb200096ac47f0245c3b51600e

That is the original error (well, part of it) that then causes the failure throttling.

The other potential conflict would be be confusion between page renaming and user renaming. But I don't think that would be a large issue.

Before:

tools.bullseye@tools-bastion-15:~/geolite$ ls -l
total 78512
-rw-r--r-- 1 tools.bullseye tools.bullseye 73069110 Aug 31  2021 GeoLite2-City.mmdb
-rw-r--r-- 1 tools.bullseye tools.bullseye  7322064 Aug 31  2021 GeoLite2-Country.mmdb

After:

tools.bullseye@tools-bastion-15:~/geolite$ ls -l
total 73872
-rw-r--r-- 1 tools.bullseye tools.bullseye 66448479 Jun 16 06:00 GeoLite2-City.mmdb
-rw-r--r-- 1 tools.bullseye tools.bullseye  9187901 Jun 16 06:04 GeoLite2-Country.mmdb

I don't like allowing uploads of image files that we don't thumbnail -- it's a moderation problem. But I definitely agree that spending any developer time on XCF support would be a waste.

In T426206#12023836, @neriah wrote:

It might make sense to enable this by default on wmf wikis. Do you think it's worth starting a discussion about it somewhere?

What accessibility testing was performed for these icons? My eyes aren't *that* bad and several of the new icons are very difficult to see & understand at a normal icon scale, especially the UserTemporary icons and HalfBright.

This process started with T211661 in 2022 with giving new thumbnails TTL (time to live).

git bisect says this is caused by rSVEC148b05474cbd: Allow overflow menu to display icon buttons for logged out users (@Jdlrobson-WMF, @bwang).

Also affecting https://meta.wikimedia.org/wiki/Special:CentralAuth/Faster_than_Thunder

That's probably a consequence of T384844 -- some password managers group all the Wikimedia domains together.

The move to login on auth.wikimedia.org has mostly fixed this for me, as I don't have any *.wikimedia.org autofill entries anymore.

There is probably too much patent uncertainty over AV1, the video encoding format that AVIF is based on, to implement this at this time.

Confirming this affects all attempts to use https://sh.wikipedia.org/wiki/Special:Preferences, and attempts to use the options API to set preferences.

4. AbuseFIlter should have UX added to manage a list of blocked domains (it may already have this) and implement the hook to compare links against this list and return null where appropriate. CSS styling and title messages would be provided by AbuseFilter.

action=view is obviously useful. action=edit is probably someone's workflow. action=info probably isn't going to break anything either way. I can't think of a legitimate reason for the rest to work.

We intentionally don't serve WebP originals for browser support reasons at the time support was added. WebP thumbnails are only sent conditionally when requested by the browser on high-use files only.

Original-size thumbnails must be supported as not all formats are web-safe.

Also getting reports of this.

Fixed with pngfix.

In T415598#11555931, @TheDJ wrote:

The ogp.me tag is listing the thumbnail variant of the fullsize, instead of the fullsize

This started happening within the last month or so. It doesn't happen for every request for every thumbnail, but seems to be more likely after the first request. Discord uses Google Cloud IPs most of the time.

Special:NewFiles doesn't appear to be as bad as it was a few years ago, but I do think it would still benefit from pregenerating the 120px/250px thumbnails.

Fixed with pngfix.

Production data loss -> UBN.

I hit this while making a check yesterday, and then ran in to it with some enwiki CUs today. Both times we were trying to copy/paste IPs into the range calculator.

I have disabled the bgpview.io queries, and the tool appears to be no longer 500ing. So that's a slight improvement.

https://grafana.wikimedia.org/d/000000371/vrts?orgId=1&from=2025-11-02T02:44:01.700Z&to=2025-12-02T02:43:01.700Z&timezone=utc&var-node=vrts1003&viewPanel=panel-30 shows inode usage steadily climbing to 100% since 2025-11-17.