Since last week we are getting editors complain about being logged out on Wikidata. Any chance this is related? T372702

For search aliases in all languages are considered. So yes mul aliases also apply to other languages. They are not shown as placeholders like labels as that would be a bit overwhelming.

Important from my side: mul should not be treated in a special way. It should just be another language code in the language fallback chain that consumers should fall back to if there is no label available in the language they are requesting. No different than for example de-at falling back to de.
IMHO this means we need an answer to how language fallbacks are handled or not in the REST API. There is T334648 for that.

Indeed. Thank you!

FYI: The EntitySchema part of this is also covered in T371196.

There is more to do. See T371752.

Team: What is the file that needs to be changed?

In T362005#10035806, @Lucas_Werkmeister_WMDE wrote:

If we go with the term store – is it okay for product that the EntitySchema search is case-sensitive? Or should we try to add a case-insensitive search based on the term store? (I think it would be relatively doable in the current SQL schema by introducing normalized labels/aliases as a separate term type, like how wb_terms used to have term_search_key in addition to term_text, pointing to the same text_in_lang/text tables. But it would take some more work, of course.)

You are probably looking for https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/Data_Model

👍

Thank you!

@Rishi2108 Great. The repository is here: https://github.com/wmde/wikidata-mismatch-finder

Can confirm it is fixed for me now. Thank you! :)

In T337013#9923203, @Nosferattus wrote:

Will this also solve T261764? or is the graph used by the Query Service different than the one used by the API?

Thank you!
@VIGNERON Is the upstream ticket something you can help with?

From my side it'd still be great to move this forward and have a better Item Quality model in Liftwing. If there is anything I can do to help please let me know.

We now have T369079 for the remaining work. Can this be closed?

This came up in the bug triage hour at the Lexicodays 2024.

Adding to our team board to get input from the team

\o/

We've discussed how to go about this problem some more. Here is the option we have come up with so far to address the problem of using the asynchronous service for synchronous work: We could have some form of local storage for the user that contains the entities they recently created. Those would be used for suggestions when making new statements.
Additional thoughts:

• One interesting step in this direction is allowing to create a new Item directly from the statement editing UI. @Celenduin has created a user script to explore how this part could look like and the details are in T107693.
• People have said that it would not just be interesting to use this local storage for the recently created entity of the user but any they have recently used. This would make some edits easier where you repeatedly use the same entity while editing many entities.

\o/

\o/

\o/

In T147821#9811891, @TuukkaH wrote:

Would this be a low-hanging fruit / papercut bug worth a triage?

If someone works on this I highly recommend not going for P18 only. There are different properties that might represent an image. We for example have a special one for coat of arms.
If you ask Wikidata for the page image for an Item it will give you one, not just from P18 but also other relevant image properties. I recommend either using that page prop or relying on the configuration that lists all the properties in the order they should be used for a usecase like this.

Just chiming in that it would be really really great to unblock @diego's work as the current model on Wikidata is not good enough to support the community in finding vandalism.

Done!

I fixed the links locally until this is fixed. These edits should be undone once the underlying issue is fixed:

• https://www.wikidata.org/wiki/MediaWiki:Sitesupport-url
• https://www.wikidata.org/wiki/MediaWiki:Wikibase-queryservice-url

I believe @AndrewTavis_WMDE was running into similar issues for T362849 and there is T363451. Does that help any?

Sorry. I fixed the image permissions.

https://www.wikidata.org/wiki/Special:Nearby#/coord/52.4973925,13.3365673 is around my place. With interface set to English:

This might become a bit worse with the introduction of the mul language code.