See T375641 for implementing this, based on my findings creating the WikibaseCirrusSearch based proof of concept.

This is how we could tackle this:

I have created an initial PoC which uses CirrusSearch for labels only, similar to WikibaseCirrusSearch (but unlike eg. WikibaseMediaInfo we can't reuse any of its infrastructure). This is mostly code copied over from WikibaseCirrusSearch and modified to both not interfere with its search fields (as we can't re-use them, because WikibaseCirrusSearch expects actual entity-entities) and to allow working with non-entity entities.

This was caused by 8006f0c5862b151f05682d4beca78e34076e93c2.

Due to problems with my local development setup (I had huge troubles setting up WikibaseCirrusSearch… while not a strict requirement for this task, I figured if I should really get that to work), I didn't manage to make significant progress here.

I already +2 the change, but the more I think about this, I'm less convinced this is the way to go here, thus I removed my +2 for now.

In T362005#10006321, @Lucas_Werkmeister_WMDE wrote:

Hm, I’ll admit this isn’t what I expected from this task 😅 I’ll leave some comments here rather than on Gerrit, since they’re pretty general:

• I assumed the main subject of this investigation would be ElasticSearch integration – after all, we’re not using the term store for searching Items and Properties in production. Did you look into ElasticSearch, or other alternative approaches to the term store? Are there known reasons why we should use the term store instead? (The main downside of the term store that I’m aware of is that any search based on it is case sensitive, at least with the current implementation. I think there are ways to make term store search case insensitive, and they would actually be useful to some third-party Wikibases, but they haven’t been a product priority so far.)

Currently my Wikidata watchlist is loading fairly slowly (~8-13s backend response time) and it's spending a lot of time (~25%) for these queries (in Linker::getRollbackEditCount). I've captured such a request in xhgui.

All usages have been removed. Wikibase's secondary CI passes, EntitySchema's CI didn't yet run after this was merged.

This seems fixed now: https://wikidata.beta.wmflabs.org/w/index.php?diff=1357826

In T362001#9773884, @Jakob_WMDE wrote:

[…]

Not sure what went wrong in T362001#9757950 - wrong property id maybe?

In T344746#9475300, @Michaelcochez wrote:

@thcipriani Can you help me out? We recently updated to a new golang version, and want to go forward getting this deployed properly.

Works with mwcli master and docker-cli 26.1.0 talking to a system wide docker socket on Fedora 39.

AFAIS this has been part of 0.23.0.

In T362001#9757106, @ArthurTaylor wrote:

[…]
I get the message that my user doesn't have permission to make edits in the property namespace:
[…]
@Lucas_Werkmeister_WMDE do you have permission?

In T143486#9679948, @Lydia_Pintscher wrote:

In T143486#9679789, @hoo wrote:

As far as I remember we deliberately chose not to auto-create users back then initially implementing this. I don't think this would be very hard to add this (in a nice way), but I haven't checked.

Do you by chance remember why? This seems like a sensible thing to do at first sight to me.

In T143486#9679761, @matej_suchanek wrote:

Has the option to automatically create the user account prior to the update if it doesn't exist on Wikidata been actually considered? Is it impossible, or is it just unclear whether we want to do it?

In T143486#9674958, @M2k_dewiki wrote:

Also see

• https://www.wikidata.org/wiki/Wikidata:Project_chat#(5000)_unconnected_television_season_articles_in_the_english_language_wikipedia_after_pages_have_been_moved
• https://www.wikidata.org/w/index.php?title=Wikidata%3AProject_chat&diff=2115538365&oldid=2114990113

AFAIS all of @ArthurTaylor PRs are merged.

In T359191#9623964, @Lucas_Werkmeister_WMDE wrote:

All the attached changes are merged – was there anything else left or is this done?

Please disregard the WikibaseLexeme changes, I accidentally attached them to the wrong task (should have been T359190).