As long as we only need to know whether an item exist and need its labels + description, I think we should only save these (and not the vast statements / claims).

Next steps, as I see them:

1. Decide if want a separate data type (Ticket TBD) --> If yes, most of the current implementation could be "kept" or we could replace it with less coupled tooling (like the handling for the commons media data type). The below assumes we stick with (something similar to) the current proof of concept implementation.
2. Refactor RemoteEntityId into RemoteItemId (also remove the dependency on WikibaseRepo), then upload a patch. Note: If RemoteItemId were to implement ItemId, we could also create proper Item objects. (*)
3. Upload a patch for RemoteEntityIdParser (*)
4. Upload a patch from the data-access/ changes (maybe changes to EntitySourceDefinitions are not needed, if we can only ever have one ApiSource for items?!)
5. T426147: [Federated Items] "federatedValuesEnabled" config needs to default to "false"
6. Decide T408517: [Federated Items] Architecture for caching/storage of remote Items + implement it
7. Upload a patch for DefaultWikidataEntitySourceAdder
8. RemoteEntityLookup (getEntity should either create a proper Entity object or we, IMHO preferably, should stop implementing the EntityLookup interface)
9. RDF related changes (we can already create entities with remote values programmatically)
10. Wire up RemoteEntityLookup so that remote values can actually be saved
11. Add a patch for RemoteEntityIdValueFormatter and wire it up (either in WikibaseRepo.ServiceWiring.php or, preferably in WikibaseRepo.datatypes.php)
12. T425574: [Federated Items] Adapt to wbsearchentities changes
13. UI (JS) changes (also wbui2025!)

Thanks for these points, Lucas. I wasn't aware of these discussion.

I just checked what MediaInfo does and it seems to represent items exactly like on Wikidata, thus by their concept id. Example: <https://commons.wikimedia.org/entity/M58831842> <http://www.wikidata.org/prop/direct/P180> <http://www.wikidata.org/entity/Q209760> . (nt) / sdc:M58831842 wdt:P180 wd:Q209760 (ttl).

I just checked what MediaInfo does and it seems that it just represents items like local items (=> there's no indication that they're not from the local wiki). Example: "datavalue":{"value":{"entity-type":"item","numeric-id":209760,"id":"Q209760"},"type":"wikibase-entityid"}}.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1261371 should fix this, once merged.

Caused by fba93304fbf0dad4f43f20d8e2a2c45a6025e9b0.

I've submitted a fix for the mw cli defaults: https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/643

This can be reproduced by setting a string to a value containing, for example {{P}}.

In T416197#11626484, @ArthurTaylor wrote:

@hoo Can you explain for product-verification purposes how users can configure this? I tested this by changing the MEX CSS, but that obviously won't work for beta / test / prod.

The query service likes (needs?!) data to be idempotent for a certain revision of an entity (for facilitating updates by difference).

This works nicely with:

I didn't test this with actual Lilypond errors, but manually changed my set up to emit the error-html.

Moving this back to ready for development, as integration tests seem to also be in scope of this task.

I don't have anything to show for, yet. If anyone wants to claim this, go ahead, otherwise I'll be back to this on Monday.

When reviewing this, please especially look for potential XSS / code injection. Other than that, the code looked good to me (I reviewed the combined diff from both patches at once).

With 08315c2031e62e3e0688f169944313e7c5bb9934 MediaWiki dropped PHP 8.1 support, making this much more urgent :/

Yes, sadly this never materialized in the way initial planned. Given I don't think I (or anyone else) will pick this up anytime soon, let's drop this for good.

Unassigning myself / moving back as I don't have a lot of progress on this, yet (ended up getting stuck on T403974#11372348).

Currently (on master / beta) adding a new entity type statement doesn't result in a drop down (but a simple text field). See: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1204644

Stumbled upon https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1204644?forceReload=true while working on this, will investigate further.

The initial patch caused T409740: Beta cluster is down due to 'No such service: WikibaseRepo.Settings', thus it got reverted. Re-submitted as https://gerrit.wikimedia.org/r/1203484.

Tested, looks fine now.

We're tackling T406844: wdio-wikibase depends on wdio-mediawiki v2 first.

After playing around with XDebug for a bit, I have to agree… I don't see any way to do this short of comparing the statement in the ChangeOp with the base revision (which is not only inelegant but also entirely at odds with the current structure of the editing code).

Adding the respective data types to VueNoScriptRendering::WBUI2025_SUPPORTED_DATATYPES does the trick.

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