This reminds me of T389199 (which ended up not being reproducible, just noting for reference).

The changes to the CSS scoping I will do on top of https://gerrit.wikimedia.org/r/1177962 tomorrow.

After more poking both on mwdebug1001 (hacking ClusterConfig::getInstance()->isDumps()) and by comparing identical runs on snapshot1015 / snapshot1016, I think that the performance differences are not reproducible anymore. Earlier on I missed that snapshot1016 has a considerable faster CPU than snapshot1015 which should explain the timing difference I saw between these hosts (which I couldn't reproduce on mwdebug1001).

One edge case that is not currently handled is links to the repo where the link text is a valid (maybe namespaced) entity id that deviates from the actual link target. An example could be: [[wd:Item:Q42395533|Q42]].

I looked into this a bit (by comparing manual script runs on snapshot1015 [which has /etc/wikimedia-servergroup] and snapshot1016). The additional time the scripts need seems to be almost completely user time and increase when lowering the batch size.

Note for parser caching: T394291#10836697

I'll have a more thorough look tomorrow or next week, but one thing to quickly test would be: Run the script with --dbgroupdefault somethingthatdoesnotexist and compare that to the speed without that parameter. AFAIR this will make MediaWiki "fallback" to the usual DBs.

Not quite sure where to leave this, so I'll put it here. Currently EntityView expects that it can produce html only depending on the language (code) that can canonically be used (and cached!). If we want to allow this feature, at least temporarily, to depend on the user (settings), we will need to break this assumption. One way to adopt the above change to T394704: [MEX] M1 - Create a beta feature (untested):

This looks pretty comprehensive for me 👍. Given it seems to no longer be possible to create such entity id objects in any way (and we use these over strings everywhere), I think we should be good!

Should this be done when we remove the feature flag (as it mentions maybe also changing the wikibase.vector.searchClient module) or just now? IMO it would make more sense to do this only once, when we feel comfortable removing the tmp feature flag.

In T371752#10815713, @Lucas_Werkmeister_WMDE wrote:

Here’s a new merged ontology file for review:

ontology-new.owl21 KBDownload

Differences to the current one, excluding whitespace:
[…]

(From the PHP 8.3 tests that passed)

While SkinAfterBottomScripts is ready for review, FormatAutocomments, WikibaseContentLanguages and GetPreferences are still to do. I'll handle them today or on Monday.

Errors I get with docker-registry.discovery.wmnet/repos/wmde/wikidata-query-gui:2025-05-05-082353 (which is build from commit b4723080315b02bacdbac45e52ca3128d489e6f1):

I've looked into the edits above a bit and noticed that both edits happened extremely close to another (1, 2), thus I think this is a case of T291377 (which has been resolved since).

This still needs an update to http://wikiba.se/ontology, though in my opinion we could defer that to the parent (T371752), which also requires an update to our ontology.owl.

AFAIS this could be resolved by either copying the file or by unpacking the temporary file directly to the target directory (could still use a different name, though).

Done: https://codesearch.wmcloud.org/search/?q=%3A%3AgetUserLanguage&files=entitytypes&excludeFiles=&repos=

Merged https://github.com/wmde/wikit/pull/692