User Details
- User Since
- Oct 8 2014, 12:01 PM (514 w, 3 d)
- Availability
- Available
- IRC Nick
- Lydia_WMDE
- LDAP User
- Lydia Pintscher
- MediaWiki User
- Lydia Pintscher (WMDE) [ Global Accounts ]
Today
Since last week we are getting editors complain about being logged out on Wikidata. Any chance this is related? T372702
Wed, Aug 14
Fri, Aug 9
Mon, Aug 5
Sun, Aug 4
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?
Thu, Aug 1
Wed, Jul 31
Tue, Jul 30
Mon, Jul 29
You are probably looking for https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/Data_Model
👍
Fri, Jul 26
Thank you!
Jul 18 2024
Jul 15 2024
Jul 11 2024
Jul 10 2024
@Rishi2108 Great. The repository is here: https://github.com/wmde/wikidata-mismatch-finder
Jul 5 2024
Jul 4 2024
Jul 3 2024
Can confirm it is fixed for me now. Thank you! :)
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?
Jul 1 2024
Jun 29 2024
This came up in the bug triage hour at the Lexicodays 2024.
Jun 28 2024
Adding to our team board to get input from the team
Jun 14 2024
\o/
Jun 12 2024
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/
Jun 10 2024
\o/
\o/
Jun 8 2024
Jun 7 2024
Jun 4 2024
May 30 2024
May 27 2024
May 25 2024
May 24 2024
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.
May 14 2024
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.
May 13 2024
Done!
May 9 2024
I fixed the links locally until this is fixed. These edits should be undone once the underlying issue is fixed:
May 8 2024
May 6 2024
May 3 2024
I believe @AndrewTavis_WMDE was running into similar issues for T362849 and there is T363451. Does that help any?
Apr 30 2024
Apr 23 2024
Apr 16 2024
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:
Apr 13 2024
This might become a bit worse with the introduction of the mul language code.