Ah I think I know what you mean, it should be on the articles themselves and not get injected via the templates.

What would be a proposed solution that wouldn't trigger the language conversion? (I assume the -{ is added for this reason.) I can get it done, just need to know what should we replace it to.

https://cy.wikipedia.org/wiki/Sgwrs_Defnyddiwr:Llywelyn2000#c-Ladsgroup-20260613005800-Incompatibility_with_Parsoid

FWIW. These pages all seem to be created by a bot. I ask the bot operator if it's okay to fix them.

There is also a lot of discussion on json global usage tracking (T370378: Explore usage tracking for chart pages and tabular data pages) that could be useful and actually shape future the normalization of globalimageslinks too (so the above ticket is correct but slightly outdated). I suggest looking at the globaljsonlinks discussion in depth too.

I think main point should be to migrate it to HTMLForm as much as possible, currently it's using HTMLForm for most but not all. Then we can switch that to codex or ooui:

Thank you for looking into this. I have sent you down a rabbit hole. Sorry 😅 I take a look and see what I can do to reduce the queries.

I created it as a public mailing list, if you wanted a private one, you can change the settings yourself: https://lists.wikimedia.org/postorius/lists/wikimedia-cy.lists.wikimedia.org

In T427285#12001447, @Yann wrote:

Ah OK, so these proposed deletions are not like usual deletions where the content is still in the database, but hidden to non-admin users?

To be clear, I'm not advocating for it to be deleted on commons (and as I said, nothing will happen without the community agreeing to it first). If there is a need for users to keep them, there is a need and we (the infrastructure) need to accommodate but if there isn't, then it'd be nice for us.

In T427285#11996375, @Yann wrote:

Hi, I don't understand why you want to delete these talk pages. Now that they exist, I don't see the point.

Hi, it was announced in tech news, and separately on wikitech-l too https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/Z2BSRHB2KVFY3EQKYWCRS7CB65IRRVD7/ I did send it to mediawiki-api-announce but it got rejected automatically :/

In T428512#11998180, @Lucas_Werkmeister_WMDE wrote:

Caching rev id of properties for an hour could save a lot of db lookups and make us more resilient towards scrapers.

And show stale labels for up to an hour, I assume?

Thanks for the thorough investigation! I want to clean them up until it becomes automated but the UI is not showing anything pending on https://lists.wikimedia.org/postorius/lists/daily-article-l.lists.wikimedia.org/subscription_requests

We can backport it to release branches for the next mediawiki releases.

Looks correct. I'll let CI run and after that, I'll merge.

Contrary to what it looks like, I have no clue what I'm doing. We probably need a service in hieradata/common/service.yaml too but not 100% sure

Yeah, we won't do this on all wikis. Only the ones that have created so many page that is adding non-trivial amount of data to the database and it will be done after the community has green-lit it. Incubator is a bit complicated since there is no community in the traditional sense but others, definitely should happen after consultation. Even before this policy, we have deleted pages in Vietnamese Wikipedia and English Wikinews before this RfC so it's a problem independent of that RfC. It's that it reminded me that we can clean up more :D

All extensions have been migrated to extension.json making the part in the title now redundant :)

There is a php extension for lzma compression but doesn't seem to be widely used: https://github.com/codemasher/php-ext-xz I can't find it in debian packages either: https://packages.debian.org/search?suite=stable&section=all&arch=any&searchon=names&keywords=php8-xz this could complicate things :(

In T18691#11991419, @stjn wrote:

Potentially instead of guessing the impact of it, maybe you could just track how many times the feature was clicked on? Seems like a reasonable use of that if you want to measure how useful it is to people.
https://www.mediawiki.org/wiki/Gadget_kitchen:_recording_metrics

TLDR: My explanation is that when someone gets to wikipedia through clicking on search engine results, they usually meant to look up a fact and then they leave. While if they are coming to us through other means (=with no referrer), they will stay and read more and click on links. Based on a simple regression, on average, every page view with referrer of none leads to 4.52 page views with internal referrer (clicking on links)

Thanks for catching there. I started looking into this now more in terms of ratios. So for example, this is the ratio of none referrer class to search engine referrer:

I thought I gave an update here. The bot is now running and compressing tiffs: https://commons.wikimedia.org/w/index.php?title=Special:Contributions/Dexbot&target=Dexbot&dir=prev&offset=20260605152652 I'll bother Matthew about dropping the old files from swift.

I made a patch exactly doing that two hours before you made the ticket and specifying exactly what to do 😅

This should fix it. cc @MatthewVernon

It tries to load the webp thumbnail on the size exactly of the original. I am sure I fixed this at php level (T418745) but somewhere in the javascript-land something needs updating

Sounds good. Thanks!

In T427949#11984904, @MatthewVernon wrote:

Wearing my WMF staff hat, I'd like to note that "we should not store uncompressed TIFFs in commons" is definitely our call to make, and "upload tooling should not upload uncompressed TIFFs to commons" likely also.

https://lists.wikimedia.org/postorius/lists/foundation-bulletin.lists.wikimedia.org/ {{done}}

That leave three wikis:

• nlwiki: Needs some work
• bnwikimedia: I don't have accounts there, it's a fishbowl wiki. I don't want to barge in via maint-script-created account either.
• bewikimedia: Uses styling that stops applying once we switch to indicator. Not impossible to fix but needs a bit of work.

yup

Moving images to under the subdomain of the wikis bring a lot of complexities. These are things to come to mind right now (and there might be more): How to do CSP. Making sure problematic files can't access sensitive cookies, how to do cache defragmentieren and so on. I personally prefer that files that anyone on the internet can upload to be served from a different domain just for the sake of security hardening but security hardening can happen somewhere else.

Is it okay if I create it under foundation-bulletin@lists.wikimedia.org given the above page?

If we have to compress it to see how much is compressed, we can simply just save the compressed version then :D

In the long term and by that time, T428086: Disallow uploading of uncompressed tiff files will be done to prevent further issues.

T428102: Request creation of tiff compression VPS project to run the bot

Creating a ticket to request a temporary cloud VPS project for it is in my todo list for today. I hope I can get to it ASAP. Sorry! but we have been thinking exactly the same ideas interdependently.

In T427949#11982519, @Nemoralis wrote:

I think one of the questions that needs to be asked here is, are many of these files really needed? Some may have educational value, but there are others that provide no information at all. I often use WikiShootMe to review and categorize images with coordinates in my country, and sometimes I find images taken from the ISS that contain nothing but darkness.

File: T428086: Disallow uploading of uncompressed tiff files

mailman is now owned by collaboration-services !

I get it done ASAP. In the meantime, do you think we can find a better name for it? see https://meta.wikimedia.org/wiki/Mailing_lists/Standardization

In T706#11980530, @aputhin wrote:

Hello! I'm the EM of the Tools Platform team, responsible for maintaining and evolving Toolforge. I'd like to be added to acl*Project-Admins so I can create milestones & sub-projects to organize my team's work. TIA!

And it can't even upload the new files:

ERROR: An error occurred for uri https://commons.wikimedia.org/w/api.php
ERROR: Traceback (most recent call last):
  File "/home/amir/p3/lib/python3.13/site-packages/pywikibot/data/api/_requests.py", line 734, in _http_request
    response = http.request(self.site, uri=uri,
                            method='GET' if use_get else 'POST',
                            data=data, headers=headers)
  File "/home/amir/p3/lib/python3.13/site-packages/pywikibot/comms/http.py", line 329, in request
    r = fetch(baseuri, headers=headers, **kwargs)
  File "/home/amir/p3/lib/python3.13/site-packages/pywikibot/comms/http.py", line 506, in fetch
    callback(response)
    ~~~~~~~~^^^^^^^^^^
  File "/home/amir/p3/lib/python3.13/site-packages/pywikibot/comms/http.py", line 389, in error_handling_callback
    raise response from None
  File "/home/amir/p3/lib/python3.13/site-packages/pywikibot/comms/http.py", line 496, in fetch
    response = session.request(method, uri,
                               headers=headers, auth=auth, timeout=timeout,
                               **kwargs)
  File "/home/amir/p3/lib/python3.13/site-packages/requests/sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)
  File "/home/amir/p3/lib/python3.13/site-packages/requests/sessions.py", line 703, in send
    r = adapter.send(request, **kwargs)
  File "/home/amir/p3/lib/python3.13/site-packages/requests/adapters.py", line 659, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', TimeoutError('The write operation timed out'))

Example: https://commons.wikimedia.org/wiki/File:LVGL-SL_-_DOP20IR_-_346000_5490000_(2025).tif

I wrote a script to proactively compress tiff files, and it works pretty nice so far:

Processing: File:LVGL-SL - DOP20IR - 345000 5489000 (2025).tif
Success! Reduced by 62.62% (75030424 -> 28043302 bytes).

Notified the uploader: https://commons.wikimedia.org/wiki/User_talk:PantheraLeo1359531#Compression_of_TIFF_files

or in other words, total storage of our originals looks like this:
https://grafana.wikimedia.org/d/75a174f3-44b6-4416-a8b8-201ad5a0c09f/swift-krinkle-copy?orgId=1&from=now-1y&to=now&timezone=utc&var-site=$__all&viewPanel=panel-37

As some data:

I updated https://people.wikimedia.org/~ladsgroup/omg/ have fun!!!

The documentation and link to automation: https://wikitech.wikimedia.org/wiki/MariaDB/Changing_user_passwords

Sure thing!

In T421705#11955130, @MoritzMuehlenhoff wrote:

After migrating pc2022 to nftables we noticed a bump of connections tracked. The root cause is that on ferm connection tracking was disabled for 3306 being the source and dest port:

• /etc/ferm/conf.d/10_mariadb_internal.conf configures NO_TRACK for the entire 3306 port (via /etc/ferm/functions.conf)
• on nftables in /etc/nftables/notrack/10_mariadb_internal.nft we only set notrack for the destination port

This is no issue for pc2022, we have plenty of headroom on it. But we should resolve this before we move further mariadb nodes.

The original file is on 120px which is a standard size, then it gets 180px which is not and gets blocked:

I love how it first appears and then disappears... I guess javascript is overriding a perfectly good thumb with a non-standard one.

Hi, is there anything I can do to help moving this forward? Thank you!

https://www.wikinews.org/?sdfwerwe

Yeah, I can deploy it a bit later today. didn't want to deploy on Friday.

Some data for Persian Wikipedia where it had the section share functionality gadget since April 9th: https://w.wiki/QTg$

Boldly declining since the wiki is now closed.

In T427465#11967928, @MatthewVernon wrote:

A couple of thoughts. I am broadly in favour of handling thumbs and originals separately :)

First - our delightful rewrite middleware uses the /thumb/ in the URI path to know to rewrite the request to the relevant thumbnail container. That middleware currently is server-hostname-agnostic (because it assumes it's always the same, as does the associated test suite). So we could at least in theory teach it new URI schemes for accessing the thumbs, but it'd need doing with care.

Yeah. It was brought up here and I asked the question there. Why do we need to build such protection? Has there been a case of uncommitted data ending up in WAN in vanilla setups? The patch that introduced it is not connected to any tickets. Also since WAN relies on callers actually passing the db object which in many cases it doesn't happen so I'd argue it hasn't done the job of that protection well but nothing ever got reported on it so I'd say it was never needed in the first place.

In T427465#11961947, @cmooney wrote:

We could eventually move MPEG-DASH files to text too, they are similar in nature.

On the QoS side we might be better keeping all video in low-priority I feel. I’m constantly paranoid of popular video ramping up bandwidth by many orders of magnitude. MPEG-DASH will help as it’s responsive, but to make sure it responds well it should be low priority. We can discuss again.

In T366938#11954768, @jijiki wrote:

Regardless of how this work will continue, I would like to iterate once more that our Redis infrastructure currently is not HA, has no fault tolerance, and it needs manual intervention in case of host failures.

That looks very unrelated and an actual problem. Can you clear the cache?

So the wiki is live now: https://conduct.wikimedia.org/wiki/Fooo

Swift ACL looks correct:

wikipedia-conduct-local-deleted:
              Read ACL: mw:thumbor-private,mw:media
             Write ACL: mw:thumbor-private,mw:media
wikipedia-conduct-local-public:
              Read ACL: mw:thumbor-private,mw:media
             Write ACL: mw:thumbor-private,mw:media
wikipedia-conduct-local-temp:
              Read ACL: mw:thumbor-private,mw:media
             Write ACL: mw:thumbor-private,mw:media
wikipedia-conduct-local-thumb:
              Read ACL: mw:thumbor-private,mw:media
             Write ACL: mw:thumbor-private,mw:media
wikipedia-conduct-local-transcoded:
              Read ACL: mw:thumbor-private,mw:media
             Write ACL: mw:thumbor-private,mw:media
wikipedia-conduct-timeline-render:
              Read ACL: mw:thumbor-private,mw:media
             Write ACL: mw:thumbor-private,mw:media

Database and other stuff has been done. Swift seems to be setting the private flag correctly:

[set-zone-access] Configuring Swift zones... 
Running maintenance script class as if executing: setZoneAccess.php --wiki=conductwiki --backend=local-multiwrite --private=1
Making sure mwstore://local-multiwrite/local-public exists...making 'mwstore://local-multiwrite/local-public' private...done.
Making sure mwstore://local-multiwrite/local-thumb exists...making 'mwstore://local-multiwrite/local-thumb' private...done.
Making sure mwstore://local-multiwrite/local-transcoded exists...making 'mwstore://local-multiwrite/local-transcoded' private...done.
Making sure mwstore://local-multiwrite/local-temp exists...making 'mwstore://local-multiwrite/local-temp' private...done.
Making sure mwstore://local-multiwrite/local-deleted exists...making 'mwstore://local-multiwrite/local-deleted' private...done.
Making sure mwstore://local-multiwrite/timeline-render exists...making 'mwstore://local-multiwrite/timeline-render' private...done.

Who should be the initial user, can you send me username and email address privately @Keegan? (in Slack maybe)

I see conductwiki.%, is now part of Replicate_Wild_Ignore_Table so it won't show up in wikireplicas.

In T424357#11958896, @Krinkle wrote:

There has been always the assumption that data in WAN is stale, at least for a bit. So I'm failing to see this fixing an actual problem that is hurting users or integrity of the data.

Stale data on read is fine indeed, because we treat reads from WANCache the same as reads from replica DBs, callers must tolerate a certain amount of lag, and otherwise require an uncached primary DB read (i.e. to inform writes during POST requests). There should generally not be a case where a read query can be satisfied by replica DB but not WANCache. The idea is that caching can be used without adding additional concens to callers.

The issue with stale DB reads is not the effect on the HTTP response (which will have a shorted CDN expiry), but the effect on future callers. Once stale data is placed into the cache, it does not self-correct.

I think as a first step, I'd like to simplify and automate this, rather than remove it. We can measure the impact with a Prometheus counter.

This would accomplish the same as your patch:

• Remove the WANObjectCache lag and since options from the public API.
• Remove Database::getCacheSetOptions method and need for developers to call it as part of boilerplate.

Exept, it would retain the protection in an automatic way, such that we automatically shorten the TTL for any WANObjectCache::getWithSet calls when a replica DB was used that is lagged outside acceptable bounds. This is similar to what we already do:

• shorten HTTP response cache to $wgCdnMaxageLagged, if lagged replica is used.
• shorten HTTP response cache to $wgCdnMaxageStale, if known-stale ParserOutput is used via lost PoolCounter lock.
• [this task] shorten Memcached expiry to 30s, if there we involved a lagged replica DB.
• shorten Memcached expiry to 1s, during the 10s hold-off period after a purge (via interim key).
• shorten Memcached expiry to 1s, if using TSE-lock option, value is absent, and lost the lock (via interim value).
• shorten Memcached expiry to 10s, if the hashed host is TKO (via mcrouter gutter pool).