I think this is a double-escaping in FormatMetadata::langItem() PNGs store Model/Make as _type: lang via PNGMetadataExtractor, so they go through langItem() which calls htmlspecialchars() on the already-formatted exifMsg() output. JPEGs have plain strings and skip langItem() entirely.

I scanned about 100k recent JPEG uploads on Commons for SOF9 markers and this is the only one. It was probably an accidental export setting, not enabled by default in any common photo editor.

In T415488#11586164, @A_diehard_editor wrote:

Update: wbEntity appears in the inspect element tab when I open a MediaInfo page, so yeah, it really is a frontend rendering bug. At this point, I'm just lost.

In T416112#11849941, @jijiki wrote:

on wikikube-worker-exp1001.eqiad.wmnet under my home dir, you can find a few traces that led to SIGABRT feel free to have a look.

Tested patch locally on Docker (MediaWiki master + WikibaseMediaInfo): adding, editing, removing, and re-adding coordinate statements all work as expected. Publish button activates correctly after changes.

Likely same root cause as T427398.

In T427398#11959873, @sbassett wrote:

Just to confirm: this does not appear to be affecting all wikis. When I try similar actions on enwiki, the reauth prompts work as expected for me.

Same cross-domain security-level desync hits Special:BotPasswords, securitySensitiveOperationStatus() loops indefinitely. Logstash shows other reauth loops too.

In T427158#11956712, @Jdlrobson-WMF wrote:

The issue here seems to be in the generation of the image https://upload.wikimedia.org/wikipedia/commons/1/14/Audrey_Nuna_at_the_2026_Met_Gala_%28cropped%29.jpg?_=20260515174212 as a gray rectangle.

In T422052#11955545, @Jdforrester-WMF wrote:

The for (const claim of claims ) {…} loop would already be a no-op, though, so this shouldn't change the response? But either way, our server code shouldn't treat this as a fatal in our code. :-)

Tagged edits can be filtered in Recent Changes:

In T427093#11955525, @Jack_who_built_the_house wrote:

@HakanIST

Some follow-up: CD is one trigger (ruwiki)

Still getting them from CD? Same error text and call stack?

Created the autosuggest-sitelink tag on Wikidata and submitted a merge request that passes it to the wbsetsitelink API call.

Some follow-up: CD is one trigger (ruwiki), but only ~13% of the total. The error also shows up on Chrome with a different message (Cannot read properties of null (reading 'parentNode') + newFromJSON in stack). Combined, it's ~830 hits / 7 days from ~57 unique UAs, mostly repeat hits from a few users.

I tried to reproduce this locally with an iOS Simulator and a standalone page using the same CSS from modalOverlay.vue.

The issue appears to have been a transient outage, the service has since recovered on its own.

I think bug is in StatementPanel.js line 160:

In T420341#11952480, @KTT-Commons wrote:

I must say I'm disappointed with the current progress, so I did some experiment on English Wikisource. I uploaded this file on English Wikisource (which is an exact copy of this file on Commons.

The result? The exact same problem is recreated. Purge? No use. Hard purge? No use. Null edit? No use. Dummy file uploading? No use. Is it somehow related to individual files?

Hopefully these additional information (that the same problem exists across projects) would be useful to resolving this problem, thank you.

I was looking at logstash for warning patterns and spotted one from WikifunctionsClientStore (~9K warnings per 12h). Submitted a fix here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/1293081

This seems related to T423818. As of now, the API returns 404 for May 22 onward and the last dump file is pageviews-20260522-110000.

This might be related to T421524 and the POC in https://gerrit.wikimedia.org/r/c/1286443. Both involve srcset handling for images smaller than the requested thumbnail size. The POC addresses CSS upscaling, but this task seems to additionally need a fix in processResponsiveImages() to avoid setting an incorrect srcset 2x when the original image cannot fulfill it.

I can reproduce this with the image in the task. It seems related to srcset. This image is 832px wide but displayed at 480px width, so a valid 2x source would need 960px. But Linker::processResponsiveImages() still sets the original (832px) as srcset 2x. The browser gets a density descriptor that does not match the actual image size and fails to render it. Removing srcset from the element makes the image visible immediately.

The above MR covers maniphest.info -> maniphest.search.

I wasn't able to reproduce this: hovercards on all three pages load thumbnails correctly (960px, via /page/summary/), and the /page/html/ responses now only contain standard thumbnail sizes.

I can reproduce this. The broken OSM link seems related to T401606: the static mapframe container is an <a> element, and the attribution links inside it are nested <a> tags, so clicks go to fullscreen instead of the OSM copyright page. The missing scale bar is expected since inline maps are static PNGs without Leaflet controls.

Tagging @Andrew since he has recent commit on the wikitech-static-docker repo. The GitLab CI pipelines have been failing since May 18.

Still happening as of today (May 2026). The login loop messages continue in #wikimedia-external-links.

This looks closely related to (and possibly a duplicate of) T239213, which describes the same imageinfo API behavior for filemissing revisions.

Then, maybe adding VISUALENHANCEMENTS to that conflict list would help here.

In T427093#11949615, @Jdlrobson-WMF wrote:

Thanks for debugging. Is there any way we can make it more obvious in stack traces when Convenient Discussions is the culprit and not DiscussionTools? Would make debugging these helpful.

Thanks for the quick fix @Strainu! I think addCharacters() might still be affected though. The symbols page seems to be lazy-loaded, so it is not ready yet when the hook fires. I still see this in the console on edit pages:

Excluding WikimediaCustomizations works. Looks like the donoridentification-donorbadge handler has TestKitchen.ExperimentManager as a services dependency instead of optional_services.

I looked into this a bit. It seems like the Convenient Discussions gadget is the trigger here, at least for ru.wikipedia.org cases.

This might just be expected behavior, as the page likely accumulated heavy transclusions over time and eventually crossed server limits once the cache was invalidated and the cumulative parse time had to be paid all at once.

The file seems to be a double redirect on Commons; passing redirects=1 to the API might help.

Here's the diff via API:

Looks like a side effect of the T424908 fix (Gerrit 1282367). It removed the isAutoGlobal() bypass from isGlobalizablePreference() but saveFormData() still unconditionally accesses $formData[$name] for every auto-global.

This seems related to T331483, specifically T359221. These modules/templates emit literal HTML headings (<h2> etc.), which Parsoid marks as stx="html" and isWrappableHeading() in WrapSectionsState.php skips them, so no TOC is generated.

In T419172#11933150, @Michael wrote:

Sorry, I totally missed your comment here! I think in my comment above I came to the same conclusion as you did. Do you want to take on the next step of fixing this?

No problem, added the isNamed() guard at the top of onBeforePageDisplay() as you suggested.

I looked into this a bit. Two things I noticed:

I'd like to propose removing istype-depicts from KIND_TO_SOURCE entirely and also addressing the FIXME by skipping suggestions where all kinds are unrecognized (instead of assigning a default source). This way depicts-only suggestions get silently skipped rather than crashing, while mixed-kind suggestions still work. I can submit a patch if this sounds reasonable.

In T425861#11928374, @Nylki wrote:

@HakanIST Hm, did you perhaps mean to comment in a different ticket? Not sure this is related. In fact I'd close this one, as the incident ( T425758 ) has been resolved.

Still seeing IllegalArgumentException from out-of-range coordinates in wikibase:box queries. One relatively low-effort improvement might be validating coordinate bounds at the proxy layer before queries reach Blazegraph.

I checked why createaccount is missing from the portlet data. It seems to be because of SUL3: on local wikis, SharedDomainHookHandler::onAuthManagerFilterProviders() filters out CentralAuthPrimaryAuthenticationProvider (TYPE_CREATE), leaving only CentralAuthRedirectingPrimaryAuthenticationProvider (TYPE_NONE). This makes canCreateAccounts() return false, so SkinTemplate.php:537 never adds createaccount to the portlet data.

In T426294#11923289, @Jdlrobson-WMF wrote:

@HakanIST can you point me to the code that is adding the account link without text?
I don't think this is a bug with Minerva. I think Minerva is making a reasonable expectation about what a link should be so I want to understand it better!

This is possibly a duplicate of T422861.

It looks like these warnings are triggered by ReadingLists\BetaFeatureHookHandler::onGetBetaFeaturePreferences() calling RequestContext::getMain()->getSkinName(), which causes a premature session load during auto-creation in Setup.php. This seems to be the same pattern as T401400 (Vector).

This is still ongoing. I tried to reproduce on a real iPhone (Safari, Chrome iOS, and GSA) and on the iOS Simulator but could not trigger it. Likely bot traffic as Jdlrobson noted.

Tested the Gerrit patch locally, all tests pass. The Clover.*West.*Virginia case now correctly extracts all 12 trigrams. Great fix!

For reference, this would be stricter than what was done for enwiki (T354013) and plwiki (T362414), which only removed obsolete-tag but kept night-mode-unaware-background-color. (Minor note: the community discussion mentions it the other way around, but the current config in InitialiseSettings.php confirms this.) Based on the linked discussion, the community seems to have agreed on disallowing all lint errors without exceptions.

In T425651#11903320, @Samwilson wrote:

@HakanIST Does the nowrap fix above solve for your MR 77 changes as well?

Submitted fix: https://github.com/wikimedia/wikipedia-ios/pull/5842

Submitted fix: https://github.com/wikimedia/wikipedia-ios/pull/5842

In T420341#11895789, @Yann wrote:

This bug causes also weird caching issues: https://commons.wikimedia.org/wiki/File:Das_Mikroskop_in_der_Toxikologie;_Beitr%C3%A4ge_zur_mikroskopischen_und_mikrochemischen_Diagnostik_der_wichtigsten_Metall-_und_Pflanzengifte,_f%C3%BCr_Gerichts%C3%A4rzte_(IA_dasmikroskopind00helwgoog).pdf
The version from 18:39, 6 May 2026 is OK but can't be displayed, and other versions are all wrong.

All 20 requested translations are now covered in the patch: 17 new magic words added, and the 3 existing ones (if, time, count) preserved with a new alias (شمېر) added to count.

SpecialChangeContentModel needs to override getLoginSecurityLevel() (and inject AuthManager) so that FormSpecialPage::execute() triggers reauthentication before the editsitejs permission check fails.

Great analysis! I tested the bandaid fix locally and it breaks existing tests (bigButNotTooBig, maxNgrams, etc.) via expression explosion, so you are right that the budget is accidentally guarding against that. The key issue seems to be that when budget exhaustion pushes a state into acceptStates, it loses all downstream trigrams, effectively severing the AND relationship between regex segments like "Clover" and "West Virginia".

After the diagnostic logging, the Logstash hits I found all point to HomepageHooks::onBeforePageDisplay() line 425. It looks like anonymous users can reach URLs with GE parameters (geclickid, gesuggestededit), and the click-ID block ends up calling suggest() with userId=0 without a registration check.

I have a local fix that adds a WikibaseSearchQueryRoute accepting COMPLEX_QUERY only when all keyword features are Wikibase-owned. But I'm not sure if this should live in WikibaseCirrusSearch or if a CirrusSearch-side solution (e.g. making BasicSearchQueryRoute extensible) would be preferred.

I looked into this locally and it seems like null-ngram transitions from wildcard ranges are consuming the maxTransitions budget (max_ngrams_extracted=100), which may cause trigrams like wev from DFA fallback paths instead of valid ones. I tested a small change in NGramAutomaton.traceRemainingStates() that only counts trigram-producing transitions toward the limit, and it appears to fix the issue while passing all existing tests.

Given this, the issue does not seem to be caused by ContentTranslation. Closing this task as Invalid, but feel free to reopen if new evidence suggests otherwise.

It seems like punkt() generates the indicator via extensionTag but returns it JSON-encoded (line 1081), and the żadna branch in Moduł:Mapa never decodes or outputs it (lines 620-627). Legacy still works because the indicator appears to be registered as a side-effect of the extensionTag call.

In T425290#11887404, @Xaosflux wrote:

Aside: is there a reliable method to access the 'mobile' layout on desktop anymore?

The target section is correctly kept visible but never scrolled to. sectionCollapsing.js init() never calls expandSectionForTarget() after setup — the hashchange listener exists but fires too late (layout has already shifted from collapsing). The legacy Toggler.js avoids this by calling checkHash() right after setup.

Submitted patches for the related T288402 and T294695 using a targeted fallback (normalize U+0130 to ASCII I only when the initial lookup fails), avoiding the concerns in T292834 and https://gerrit.wikimedia.org/r/1116533 about changing ucfirst globally. A similar approach could work for AllMessagesTablePager here.

Related to T294695, T292905, and T292834. All caused by Turkish ucfirst mapping i to İ (U+0130) when applied to English identifiers.

This effectively makes the GIPBE not work during autocreation. Removing the CentralAuthStrict gate in onUserGetRights() to match onUserIsLocked() seems like the right fix.

Both this and possibly T425172 look like fallout from T392356, since Envoy seems to enforce what ingress-nginx tolerated. For the empty 204, dropping @validate_response on the handler and returning Response(status=204) directly should bypass quart-schema's serialization, if you ever want to revisit the 200 workaround.

Could this be the return {}, 204 in api_config_refresh()? Quart sends that as a 3-byte JSON body, which Envoy may reject since 204 must not have a body per RFC 7231. return '', 204 should fix it.

In T409263#11882070, @M2k_dewiki wrote:

Hello, from my point of view, disambiguation items should also look for

"Wikimedia human name disambiguation page"
https://www.wikidata.org/wiki/Q22808320

Example:
https://www.wikidata.org/wiki/Q10556469

Thanks a lot!

In T420341#11882020, @KTT-Commons wrote:

Like to ask what was changed on 23 April? As a matter of following up the change, nothing has changed with respect to this file.

In T424439#11879297, @Dreamy_Jazz wrote:

MarkPatrolledComplete doesn't pass the associated log ID, so we will need to update that to pass it to the hook handlers

Hi, I looked into it and it seems like this particular article wasn't created through ContentTranslation. The creation revision doesn't have the usual CX tags: