(Making this a direct subtask of T394621 for now, though it should probably be moved around – T415326: [MEX] M5 - additional functionality and clean up?)

I think something similar happened in SpiderPig #1723 (cc @hashar), where it complained that “The change '1269334' failed build tests and could not be merged”, but in fact it was only the main test build that failed; the gate-and-submit passed and the change was merged, but scap had already exited, resulting in undeployed merged changes that needed to be cleaned up with another scap.

In T400325#11803458, @ArthurTaylor wrote:

As long as we have the data bridge enabled (which is the case on Wikidata in production)

In T388907#11800673, @Lucas_Werkmeister_WMDE wrote:

I already get much better results if I divide the radius by three instead of four

Hm, apparently the label truncation is just based on a very simple heuristic… I already get much better results if I divide the radius by three instead of four:

In T416160#11712294, @Func wrote:

Also note that there is an invalid API call with value= (empty string) to action=wbparsevalue

I mentioned this on Gerrit but it seems worth pointing out here too: our effort to display useful errors in HTML is somewhat hampered by the weird structure of errors in Wikibase API responses – see T304945. Maybe now is a good time to tackle that task.

aaaaaa the statement ID contains the item ID of a different item than this one

Okay, that’s wild.

Alright, then I guess we can close this.

Sounds like it could be the same issue as T421633: ChronologyProtector not working reliably on the REST API…

That said, on my wiki (and also on Wikidata), oojs-ui-widgets is also pulled in by ext.echo.ui, so we won’t get rid of it via WBQC alone. (@ArthurTaylor I’m guessing you don’t have Echo installed?)

But that would just be a page in the main namespace, wouldn’t it? E.g. that wiki’s main category is Category:Wp/grc, not Wp/grc/Category:something; similarly Template:Wp/grc/Infobox.

OOJS is much smaller than OOUI though.

Are there any potential issues between the “specialness” of the Incubator and CampaignEvents? E.g. would there be events like Event:Wp/grc/something for the Ancient Greek Wikipedia, and should they be handled / displayed in a custom way?

Looks good to me, thank you!

In T414454#11547893, @ArthurTaylor wrote:

@Arian_Bozorg good question. I'm not really sure. @Lucas_Werkmeister_WMDE expressed some skeptiscism about this and T414455, which I think is fair. It might make sense to think about all three tickets as a group and decide what experience we want to have before working on any of them individually.

Thanks!

The fix should be deployed now (thanks swfrench!); lowering priority and leaving the rest to y’all.

The full job list, sorted by “last build”, shows some builds are still registering, but not a lot:

Timeline note: this comes hot on the tail of T422130, for which @jasmine_ repooled codfw slightly earlier than scheduled (which seems to have helped with that issue). Not yet clear if this is related or not; @jasmine_ is looking into it (see also #wikimedia-operations IRC log).

Noting that part of our motivation for turning on video recordings was painful experiences with flaky tests that seemed tough-to-impossible to debug from the final screenshot alone. So I don’t think “making it easy to enable [video recordings]” when you actually have failing test[s]” would work very well, because it would mean we mostly don’t have recordings for the flaky tests. On the other hand, recording videos for retries would be fine, I think (either the retry still fails and we have a useful video, or it passes and then we don’t really care because it didn’t block CI).

Other task time note: @AudreyPenven_WMDE noticed that this actually already works for statement ID URLs (they’re not highlighted, but it does scroll to them): https://www.wikidata.org/wiki/Q42?useformat=mobile#Q42$1d7d0ea9-412f-8b5b-ba8d-405ab9ecf026
But property ID URLs are still missing: https://www.wikidata.org/wiki/Q42?useformat=mobile#P735
We agreed that we don’t need to add id= attributes for property IDs before we have the design.

Suggestion for what the config could look like:

I don’t see what reliability has to do with it? We wanted to know the impact of adding a bunch of namespace aliases in many different languages (would this “shadow” any existing pages?), and it seemed to me that the best way to do that would be to dry-run namespaceDupes on all wikis, with the patch experimentally applied, and then inspect the maintenance script’s output (and compare it with a “regular” dry-run without the patch).

Timing coincides with T422130. Coincidence?

• mwversion: 1.46.0-wmf.22
• timestamp: 2026-04-02T10:41:51.734Z
• phpversion: 8.3.30
• reqId: 87a3a1b9-4e3a-4521-a0b6-3d4afc1e6191
• Find reqId in Logstash

It would also be great to be able to run maintenance scripts on multiple wikis (i.e. an equivalent of foreachwiki or mwscript-k8s --dblist) on mw-experimental. I tried out P84273 and couldn’t see a way to do it there, just individual wikis:

Also the advertised curl install via copy-pasted pipe in the README also is broken before this point in fetching the install script itself.

Which Blazegraph-specific syntax does the query builder use? I tried out an example query and the result is standard SPARQL syntax AFAICT. (It uses the label service, which is a custom feature, but syntactically that’s just a ServiceGraphPattern like for federated queries.)

Some things that will need updating in SparqlHelper, off the top of my head:

I guess so (the last result is from Jan 4, 2026 @ 13:31:55.192). Hooray!

In T385454#11726650, @Aklapper wrote:

Still happening in 1.46.0-wmf.20:

• service.version: 1.46.0-wmf.20
• timestamp: 2026-03-19T08:31:11.503Z
• labels.phpversion: 8.3.30
• trace.id: 55be2bf3-bcfd-47e8-ba3a-7395bf8b8eaf
• Find trace.id in Logstash

Not sure, I haven’t used them much myself. (Otherwise I’m also fine with just leaving it alone.)

Ah, I see… so I guess we have several issues. (Also, I would suggest putting “93.522,56.253” back in the issue description, as that’s the string I reproduced the issue with. You can’t reproduce it with “93.xxx,56.xxx”.)

Interesting:

I guess we can make EntityHandler::getPageViewLanguage() return StubUserLang::unstub( $wgLang )? (Or StubObject::unstub( $wgLang ); core seems to do both.) Or try to figure out what’s going on in more detail…

There shouldn’t be a lot of special setup needed – install Wikibase (master, not any release branch), make sure composer dependencies are installed, enable $wgWBRepoSettings['tmpMobileEditingUI'] = true; (and $wgWBRepoSettings['tmpEnableMobileEditingUIBetaFeature'] = true; if you want it as a beta feature instead of unconditionally enabled), install MobileFrontend and load pages with ?useformat=mobile. (Some data types would need additional extensions and/or configuration but it doesn’t sound like that should be relevant here.)

Dev note: if I add z-index: 450 to the .oo-ui-windowManager-modal > .oo-ui-dialog styles, then the fullscreen map shows up on top of our UI correctly, rather than below it.

Still happening. https://integration.wikimedia.org/ci/job/mediawiki-composer-php84/120/console

Similar issue for Wikipedia search: T420427: Search shouldn't trim trailing space when suggesting suggestions

Similar issue for Wikidata search: T417648: [MEX] M4 - improve findability of properties on lookups

Update, now that Hackathon-Northwestern-Europe-2026 is complete: Most of the plan at T231755#9772825 should be done, see the Gerrit changes above. We can’t test anything with a new CLDR version yet because the extension is currently on the latest version (though, looking at the calendar, I think a new upstream release might happen soonish?). Fuzzy stuff is also not done yet.

I wonder if there’s a nonintrusive way we can communicate our decision here to upstream Composer? I would think that they might be interested in “large” users disabling this functionality, for potentially evaluating it. A GitHub issue probably isn’t the best way, but maybe one of us has a personal contact?

I think this was done with the above change (and some subsequent update to the hosted ontology file in the 3½ years since then), the MusicalNotation type is now included in https://wikiba.se/ontology. (Which isn’t the same URL as in the task description, but that’s a separate issue.) Boldly closing.

I’m picking up this task again at Hackathon-Northwestern-Europe-2026 :)

Previous version: P61867

I think @ArthurTaylor already fixed this earlier today (edit: SAL), unless you still see it happening?

(Just for the record, since I already looked it up: the acceptance criterion “Invalid input can be saved” was originally added in T208489#4927651, presumably during a story time meeting.)

I think resource-wise, adding a validator for musical notation values should be fine, as it would only run when those values are added or changed, which should be pretty rare in the grand scheme of things.

Well, Wikibase CI is still (or again?) broken due to the Scribunto changes, but it’s a slightly different issue: T419371: Test failure in quibble-with-WikibaseClient-extensions-tests-php83 - Capiunto extension

I have a working Score setup and can confirm that the patch fixes the stored XSS. The popup on the SVG stops appearing as soon as the new SVG is loaded, though the popup on scores is broken until the pages are purged (so the data-* attributes in the parser cache turn into data-mw-* attributes). CR+1, should be okay to deploy and then ideally purge the affected pages at least on major wikis (e.g. action=purge + generator=categorymembers + gcmtitle=Category:Pages using the Score extension + gcmlimit=max, then sleep and follow continuation until done; category name varies by wiki).

Um, are you sure you want this task to be public? (The “further information” link isn’t public – GitHub tries to hide obscure this information from non-developers to some extent.)

I thought the intention behind this task was to prevent these edits server-side, not to make some of our frontends stop trying to save them. AFAICT, the linked patches still allow other API users to save invalid statements.

Alright, thanks for the fix!

Thanks. I guess this is just a dupe of T415451 then? The number of errors is slightly different (that task only reports 6 copies of “Database backend disabled”), but it seems to be all the same errors.

Yup, https://codesearch.wmcloud.org/search/?q=public+static+function+suite%5C%28 finds the suite() override in WikibaseLexeme and a handful of unrelated ones in core. (You can also limit the search to subsets of repositories, e.g. “MediaWiki & services at WMF”.)

I think this is because Wikibase CI pulls in the ParserMigration extension, which doesn’t seem to be enabled in MobileFrontend’s CI, so whatever the issue is, it wasn’t noticed in MobileFrontend itself.

Instead, each test class becomes abstract with two concrete subclasses
(*SandboxTest/*StandaloneTest) that implement getEngineName(). Engine
availability is checked via markTestSkipped() in setUp(). Group
annotations (@group Lua, LuaSandbox, LuaStandalone, Standalone) are
placed on the concrete subclasses.