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

https://gerrit.wikimedia.org/r/c/1134693 needs to be deployed and http://wikiba.se/ontology needs to be updated.

In T391089#10746455, @ArthurTaylor wrote:

Looks like it's failing with some parsing errors:
[…]
https://integration.wikimedia.org/ci/job/mwgate-node20/38786/console

Added a browser test setup similar to the repo one for client, and created a very trivial test making sure the linkitem pop up loads. The test fails for me after reverting 09281858f21eb5d8a34666ce599fa130c519b7f4.

Release is out: https://github.com/wmde/eslint-config-wikimedia-typescript/releases/tag/v0.2.13

The decision outline above sounds good to me. As creating the ADR is part of the scope of this ticket but also tracked as T391438, I think this best fits into parent tasks for now?!

AFAICT the remaining open changes are all blocked on this being deployed/ the setting being set.

Change merged, but I don't have the rights to deploy it (don't have access to the phpunit-results-cache tool).

Root cause here is that we relied on doxygen's page reference names, but those are not stable across releases. Given they seem to be undocumented I don't think they are supposed to be used.

I didn't manage to make much progress. Current state in @AudreyPenven_WMDE's https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1123003.

After 85f3478386615aa1bdb6dd6929fb5b75ea65b1ff this seems to work analogue to items and properties: https://wikidata.beta.wmflabs.org/wiki/Lexeme:L1?vectornightmode=1&useskin=vector-2022

I still have trouble getting this to run locally, thus I don't have much to show off right now.

Potentially related, the last ttl dump failed with:

This happens for Q4941387, which currently has a statement with (non-existing) P107 for which "The value is invalid and cannot be displayed.". This seems like the probable cause for this.

https://github.com/wmde/lib-version-check/pull/8 After that is merged, I (or someone else) can archive the repo.

As of commit fe03480d59f7fa15e1c554255c7f3b279a16f406 the foreign resources file contains version numbers, thus we could change the library to support this (require yaml, load the file, read the version number by key). But I wonder whether we still want to do that, and if yes, do we want to change (or widen) the scope of the current tool or even create something new?

Unassigning myself, won't be able to look into this before Tuesday.

This should be the final update, then we can bump the submodule.