Wikidata:Contact the development team/Archive/2020/12

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Template:Cite Q (Q22321052) and deletions

Going forward it's not only valuable when Wikipedia items are linked via sitelinks to Wikidata but also when templates like Template:Cite Q (Q22321052) are used within Wikipedia. At the moment the deletion dialog warns if an item is linked within Wikidata but it doesn't warn if the item is used in Wikipedia. This means that an admin who looks at an item doesn't see that he breaks something on a Wikipedia when the admin decides to delete the item. If Template:Cite Q (Q22321052) is used more widely this will likely produce conflicts with individual Wikipedia's who will use it as a reason to argue against the adoption of templates like Template:Cite Q (Q22321052).

I made a property proposal to make the information about providing the information about how an item gets used on via a Wikidata property but it looks like this is going to be rejected. While this information is available by checking page information, I would expect that most admins don't look at the page information tab for every item they are looking to delete as that would complicate the deletion workflow.

I think the information should either be available on the normal item view in a similar way to how the sitelinks are displayed or should be available in the form for deleting items. Having a SPARQL way that allows to query this information would also be valuable and useful when advocating that individual Wikipedia's use Template:Cite Q (Q22321052). While at the moment Template:Cite Q (Q22321052) feels like my main concern in the future lists that rely on Wikidata will face a similar issue. ChristianKl ❪✉❫ 13:37, 10 November 2020 (UTC)

What links here is probably the place you'd hope to find a list of language wiki uses of the item - e.g. https://www.wikidata.org/wiki/Special:WhatLinksHere/Q56603081 for one of the references on the model article, https://en.wikipedia.org/wiki/South_Pole_Telescope . I note that Commons does not have the same problem - see 'File usage on other wikis for an image such as https://commons.wikimedia.org/wiki/File:Perchtoldsdorf_Pfarrkirche_Innenraum_01.jpg --Tagishsimon (talk) 14:12, 10 November 2020 (UTC)
We could also have admins stop deleting good items, out-of-process. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:57, 10 November 2020 (UTC)
That assumes that all items would look to be good. I can for example see that some press releases of a company might want to be referenced on Wikipedia but we don't want that every SEO person creates an item on Wikidata for every one of their press releases. ChristianKl ❪✉❫ 17:28, 10 November 2020 (UTC)
AFAICT, none of the items referred to are press releases, nor in any way "not good". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:21, 1 December 2020 (UTC)
Given recents events in the project chat I found an item that was deleted but used over at enwiki (enwiki is subscribed to it): Q89412367 (I undeleted it). The quality of the item isn't easily distinguishable from SEO spam that we do want to delete. ChristianKl ❪✉❫ 23:41, 1 December 2020 (UTC)
I actually started working on a user script some time ago to list item usage on the delete page (also on the "page information" page so that it's visible somewhere other than the delete page). It's currently at User:Nikki/ItemUsage.js if anyone wants to try it. - Nikki (talk) 22:21, 19 November 2020 (UTC)
I was stunned and disconcerted this morning to learn that Q59318277, which I cited 2018-12-04 in Wikiversity:Great American Apardox, was not a valid QID. My first reaction was to fix the immediate problem by creating Q102951790. If I had not recorded a page number with that citation ({{cite Q|Q59318277}}, p. 89.), I might not have been able to fix that broken link with the time available for a task like that.
Then I began to consider the systemic implications of this problem. One is that there is no obvious easy way to identify "File usage on other wikis" as there is on Wikimedia Commons, as noted above. If they can do it on Commons, the Wikidata developers should be able to do it.
It's not just Q59318277. I've since learned that five other Wikidata items I've created have been deleted. The documentation on those deletions is so poor, I don't know how to determine if the deletions are legitimate or are other examples of deficiencies in Wikidata's deletion procedures.
Any deletion procedures should require prior notification of all the users (apart from bots) who made edits to that Wikidata item. DavidMCEddy (talk) 01:41, 2 December 2020 (UTC)

If I understand correctly, some Wikidata times are deleted, because they don't have an external reference. That should be easy to fix in advance by checking each Wikidata item for an external reference and flagging it if it doesn't have it. For new Wikidata items, users should be told that the item will be deleted if the problem is not fixed in, e.g., 72 hours, I think. For existing Wikidata items, if deletion is contemplated, emails should be sent to all humans who contributed to that item, informing them of the deficiency, and giving them a date, e.g., 72 hours in the future, at which time the item would be deleted.

I use Wikidata extensively for citations. If I want to cite "something" by "firstName lastName", I first create a Wikidata item for "something". If it's on the web, I nearly always include "full work available at URL". If it's only described on the web I use "describe at URL" or "reference URL". If Wikidata items are deleted, people who create them should know.

Secondarily, if I create a Wikidata item by mistake, it's not obvious what I should do about it. The page for each item should make it easy for a user to find out how to report an item to be considered for deletion and what the deletion criteria are.

If Wikidata items are deleted in part for not having an external reference, users should be warned before deletion and informed on how to avoid that!!!

Thanks, DavidMCEddy (talk) 01:41, 2 December 2020 (UTC) 


DavidMCEddy (talk) 01:41, 2 December 2020 (UTC)

add monolingual code "und-latn"

Tracked in Phabricator
Task T267636

Would you kindly prepare to add this to the list of codes? "und-latn" would be for undetermined language written in Latin script (Q101416598).

I asked for community input at Property_talk:P969#"und"_or_"und-latn". It also lists a series of usecases. --- Jura 09:28, 10 November 2020 (UTC)

I created the task and asked for feedback from some LangCom people. If we don't get any veto within 2 weeks, we can move forward with it. Lea Lacroix (WMDE) (talk) 12:19, 10 November 2020 (UTC)

@Lea Lacroix (WMDE), Mbch331: Thanks for looking into this. Seems we are just about to move ahead with it. --- Jura 15:17, 22 November 2020 (UTC)

@Lea Lacroix (WMDE), Amire80: It seems to have been missed, but the language code will be used on street address (P6375) that is not deprecated and was chosen to replace P969 (P969).I suppose codes like "ru-latn" or "ja-latn" (or "ja-latn-somemethodoftransliteration" would be possible, but is it really useful for street addresses? Unless we get some constructive, actionable input what to use instead, I think we should move ahead with this. --- Jura 09:00, 25 November 2020 (UTC)

It's a monolingual string just like any other. Street names are written in a language, and this language is a known one, not "undetermined". If there are people who can write monolingual string values in the correct writing system for native names, etc., certainly there are people who can do it for streets. --Amir E. Aharoni {{🌎🌍🌏}} talk 09:03, 25 November 2020 (UTC)
@Jura1: Per comment, could you provide more examples on how the code would be used apart from addresses? Lea Lacroix (WMDE) (talk) 09:12, 25 November 2020 (UTC)
@Amire80: I think the consensus is to determine the applicable language code and convert the values, not to delete values for which the devs haven't created the applicable language codes. Language may be native language in the main script, but it could also be written in Latin script. In some countries, this is actually seen as a driver for accessibility to tourists. For langcom input to be constructive and actionable, I'd expect to see advice for each sample what code the committee deems acceptable. --- Jura 09:24, 25 November 2020 (UTC)
All the examples I've seen are simply values that should be corrected. A language code is a strange way to address this. There are lots of values that could be wrong, which are not necessarily monolingual strings. There must be another way to denote a value needs checking or correction. --Amir E. Aharoni {{🌎🌍🌏}} talk 10:00, 25 November 2020 (UTC)
Can you explain how the should be corrected, i.e. what the correct values are (per langcom) ? --- Jura 10:01, 25 November 2020 (UTC)
On the most simple level, the street names should be written in the appropriate alphabet of the language. If anyone things a transliterated street name is useful, there should be some structure for it, like another property or a qualifier, or simply a value in English. I wouldn't use things like ru-latn or ko-latn for that. A transliteration is not a text in a language, but an auxiliary representation. Such codes may be legitimate for ancient or reconstructed languages, which were not written in real time, or where modern researchers find transliteration more useful than the original. But for modern addresses there should be something different. --Amir E. Aharoni {{🌎🌍🌏}} talk 10:10, 25 November 2020 (UTC)
@Amire80: would you kindly quote the relevant IETF standard/applicable codes? Please bear in mind Help:Monolingual_text_languages when advising here on Wikidata. I suppose langcom isn't meant to editorialize on individual projects. And no, transliterated languages aren't in English by default. --- Jura 10:19, 25 November 2020 (UTC)
It's not supposed to be done with language codes at all. --Amir E. Aharoni {{🌎🌍🌏}} talk 10:33, 25 November 2020 (UTC)
@Amire80: What isn't supposed to be done with language codes? The question here is if the language code is "und", "en", "und-latn", "ru-latn", "ru-somethingelse", "somethingother". It's not a venue for langcom to editorialize on Wikidata. --- Jura 10:40, 25 November 2020 (UTC)
All the examples you've brought up are examples of information that is either wrong, or defined in some inconsistent or non-standardized way. Wrong information is not supposed to be marked with a language code. Language codes are for marking that a piece of information is in a certain language, not for marking it as suspect, wrong, or non-standardized. --Amir E. Aharoni {{🌎🌍🌏}} talk 10:45, 25 November 2020 (UTC)
Can you provide us with the values that would be correct? Wouldn't the langcom view that "und" shouldn't be used in Wikidata be editorializing? --- Jura 10:49, 25 November 2020 (UTC)

Vandalism of Angela Merkel persisted in the Wikipedia App

Tracked in Phabricator
Task T269003

See https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Vandalismus_in_Wikipedia-App . It seems like the Wikipedia App showed Angela Merkel for a day as dictator of Germany even so I reverted the change 50 minutes after it was made. Given the current political climate it isn't really that funny. ChristianKl ❪✉❫ 22:00, 28 November 2020 (UTC)

Some more background: the German description of Angela Merkel (Q567) was vandalized here and reverted here some 50 minutes later. The Wikipedia app for Android continued to show the vandalized description for some hours on the article page of Merkel (but not in the search results, as much as I am aware); this was confirmed by several users, many of them did not open the corresponding article on their smartphone earlier. In other words: apparently some server-side cache was not renewed when the vandalism was removed.
Today I looked into this a little more based on other German description vandalism cases, and I was able to reproduce the observed behavior in other items as well. My current hypothesis is that use of rollback when removing vandalism does not trigger the app to load the changed description, but use of undo does (and any modification in the web UI also makes the app to use the new description immediately). I thus suggest to review whether old content in caches is properly invalidated when rollback was used, as this is sort of the standard tool to combat vandalism and it would be a pretty blunt one if it does not reliably remove vandalism everywhere. —MisterSynergy (talk) 13:23, 29 November 2020 (UTC)
Thanks for the report. Pinging @Johan (WMF): as this is related to the Wikipedia app. Lea Lacroix (WMDE) (talk) 07:56, 30 November 2020 (UTC)
Thanks, I've started a discussion about this in the Android team chat. /Johan (WMF) (talk) 09:34, 30 November 2020 (UTC)
@Johan (WMF): Thank you! Please provide the Phabricator-Task number once there is one so we can the progress on this issue. --Count Count (talk) 11:50, 30 November 2020 (UTC)
Will have a Phab task for you soon – we've also, like MisterSynergy, found other examples while discussing this in the last hour. Thanks everyone for investigating and pointing out the problem. /Johan (WMF) (talk) 14:20, 30 November 2020 (UTC)
See Phab:T269003. /Johan (WMF) (talk) 15:23, 30 November 2020 (UTC)
So is it correct to say the perceived vandalism problem at Wikidata may actually be a caching problem at Wikipedia? --- Jura 10:56, 4 December 2020 (UTC)
I guess it is safe to say that several factors play a factor here. There is with no doubt vandalism in Wikidata which is not reverted quickly enough; based on my patrolling efforts in the past weeks I would say that it is not a huge problem, and certainly one that can be solved if editors would engage in patrolling a little more and for instance patrol all the changes in their native language once a day. Except for English, all languages can be patrolled by a single editor, although three to five patrollers are a more sustainable setting for es, fr, de, it, ru.
That said, some of the vandalism visible in the apps might indeed have been reverted earlier, but the cache was not renewed. Meanwhile they have changed the software per this ticket, and I am no longer able to reproduce the reported problem. —MisterSynergy (talk) 11:52, 4 December 2020 (UTC)
If my understanding is correct, any vandalism (notably in descriptions), reverted by a patroller in the last 8 year, remained present in the mobile version of Wikipedia. One might even say that patrolling made things worse as regular edits actually purged the cache.--- Jura 12:06, 4 December 2020 (UTC)

Change P920 property’s data type from “string” to “external identifier”

Tracked in Phabricator
Task T269205

P920 is a Q89560413 like P1014 [this is the first time a write a petition in this forum, I hope I did this properly] cc @Epìdosis: Silva Selva (talk) 23:36, 29 November 2020 (UTC)

Thanks @Silva Selva: Is there a community discussion somewhere about it, and if not, could you ping the related WikiProject or people who contribute to this topic? We want to be sure that people involved agree with the change before moving on. Lea Lacroix (WMDE) (talk) 07:59, 30 November 2020 (UTC)
Great idea @Lea Lacroix (WMDE):! I just wrote this same petition in the Authority Control WikiProject and added you with a ping, let me know if that's correct, I'm still learning! Silva Selva (talk) 17:24, 30 November 2020 (UTC)
 Support Given that there are no unique value constraint violations it seems like a clear “external identifier”. ChristianKl ❪✉❫ 14:01, 1 December 2020 (UTC)
It is listed at Wikidata:Identifier migration/0#Not going to convert (page from 2016), but the reason not to convert it—many duplicated values—apparently does not apply any longer. —MisterSynergy (talk) 00:16, 3 December 2020 (UTC)
It seems the property was hardly used before recently. So back in 2016, there wasn't much to determine whether it should be converted. --- Jura 10:55, 4 December 2020 (UTC)

Article in languaje section lacks spanish, but the article already exist

Hello,

In this article: https://en.wikipedia.org/wiki/Arecibo_Observatory lacks the Spanish language option. But there's an article that exists already. This one. https://es.wikipedia.org/wiki/Radiotelescopio_de_Arecibo.

I did tried to add the link manually but the following error appeared:

Could not save due to an error. The save has failed. Site link eswiki:Radiotelescopio de Arecibo is already used by item Q44547. Perhaps the items should be merged. Ask at d:Wikidata:Interwiki conflicts if you believe that they should not be merged.

P.D. I hope this problem can be resolved. I spent 3 hours translating this page for nothing because I thought there wasn't a Spanish translation.

Best Regards. EH.

There is nothing to fix. The radiotelescope was one of the instruments at the observatory - which is to say, the observatory is not the same as the radiotelescope. So there are items for both, and language wikipedias have articles either on one, or the other, or both. --Tagishsimon (talk) 23:17, 3 December 2020 (UTC)

Hello, I don't know where the problem is (on the fr wiki or on the sparql query landing page), could you please help me finding where the pb is, so that I could lag a phabricator properly? Steps to reproduce the error: - with a PC (OK) : go to https://fr.wikipedia.org/wiki/Liste_des_a%C3%A9roports_les_plus_fr%C3%A9quent%C3%A9s_en_Oc%C3%A9anie#En_graphique . Hit "Voir la requête sur le moteur Wikidata." and all should be OK (SPARQL code within the query service). - with a smartphone : go to https://fr.m.wikipedia.org/wiki/Liste_des_a%C3%A9roports_les_plus_fr%C3%A9quent%C3%A9s_en_Oc%C3%A9anie#En_graphique . Hit "Voir la requête sur le moteur Wikidata." : the landing page is blank (no sparql inside). Thanks Bouzinac 💬●✒️●💛 09:29, 3 December 2020 (UTC)

I can’t reproduce this issue – with a mobile phone (Firefox Android 83), and going through fr.m.wikipedia.org, the query still loaded and I was able to run it as well (352 results). --Lucas Werkmeister (WMDE) (talk) 11:25, 3 December 2020 (UTC)
Creepy. Here's the screenshot of the wikimedia smartphone app File:Screenshot 20201203-125135 Wikipedia.jpg and the result, after hitting the button File:Screenshot 20201203-125147 Chrome.jpg... Would there be a difference between being in the browser // the Wikimedia app? Bouzinac 💬●✒️●💛 11:56, 3 December 2020 (UTC)
Probably doesn’t depend on browser/app, since I can see the URL with #SELECT… in your second screenshot… not sure why it doesn’t work, then :/ --Lucas Werkmeister (WMDE) (talk) 10:33, 4 December 2020 (UTC)
I think it happens when javascript is de-activate or not working for some reason. --- Jura 10:54, 4 December 2020 (UTC)
No, if JavaScript was disabled, then the page would look different. --Lucas Werkmeister (WMDE) (talk) 11:32, 7 December 2020 (UTC)
Strange, I can indeed reproduce this: screenshot via app, screenshot via browser. Looking at the address bar, it seems the URL is being escaped slightly differently? Not sure if that puts the blame on the Wikipedia app or the query service UI, though (i.e., whether the app should encode the URL differently or whether the UI should still load the differently loaded URL). --Lucas Werkmeister (WMDE) (talk) 11:17, 9 December 2020 (UTC)
Pinging @Johan (WMF): to see how this might be related to the Wikipedia app. -Mohammed Sadat (WMDE) (talk) 11:53, 9 December 2020 (UTC)
Thank you for the ping. This is, indeed, unfortunately related to the app, as it doesn't support the JavaScript chart. There are sometimes limitations in the apps when it comes to illustrations; for another example, the iOS app can't show any video in the articles, as there's no overlap between formats supported by iOS and allowed on Commons. /Johan (WMF) (talk) 05:10, 11 December 2020 (UTC)
  • gallery of screenshots

Special:Contributions broken

https://www.wikidata.org/wiki/Special:Contributions/RenzoCastro25 gives:

[X86uewpAEKIAANt5KPgAAADN] 2020-12-07 22:36:43: Fatal exception of type "Error"

I get the same problem with other users. Bovlb (talk) 22:38, 7 December 2020 (UTC)

Ah, and now it works. Never mind. Bovlb (talk) 22:39, 7 December 2020 (UTC)
Thanks for reporting, I'm not sure what went wrong, but I'm glad it didn't last for long. Let us know if it happens again. Lea Lacroix (WMDE) (talk) 07:06, 8 December 2020 (UTC)

Wikidata Query Service prefixes for wikimedia interwiki links?

Hi, would it be possible to add prefixes or custom renderers for all wikimedia wikis interwiki-links in query.wikidata.org. Altenative could be that it would render all queries defined PREFIX:s in short form and not as full url.

So the link (example query)

would be rendered as

--Zache (talk) 11:37, 1 November 2020 (UTC)

Hello Zache! To be sure that I understood what you wrote: do you mean you'd want to see the rendering for the Wikipedia links in the 'article' column in the query shortened to, from say https://fi.wikipedia.org/wiki/Min%C3%A4_ja_Morrison to w_fi:Minä_ja_Morrison. If so, do you mind letting us know why you think that'd be better? Thanks. -Mohammed Sadat (WMDE) (talk) 15:51, 2 November 2020 (UTC)
If the column is shorter then there is more space per row when results are rendered as "table". Also the urlencoded urls arent very human readable. So the functionality what i would like to see is that
  1. the value of the column is human readable name of the wiki page
  2. the value of the column is still hyperlink to that page.
However, in i don't feel that i would need this for writing queries. --Zache (talk) 19:52, 3 November 2020 (UTC)
Some like https://w.wiki/jyS could be interesting (with links to fiwiki, as they would be here). --- Jura 20:38, 3 November 2020 (UTC)
I don't personally see a need for close to 1000 new prefixes to use in sitelinks, but if these new prefixes come then I suggest using the existing and already known database names (values of Wikimedia database name (P1800) as "fiwiki", "dewiktionary", "idwikiquote" etc.) instead of inventing a whole new set of codes to learn. --Dipsacus fullonum (talk) 18:32, 4 November 2020 (UTC)
Actually if we want just working redirect and not permanent id's then one redirect like https://www.wikidata.org/wiki/w:fi:Minä_ja_Morrison -> wiki:w:fi:Minä_ja_Morrison would be enough for all the wikis in the wmf cloud . --Zache (talk) 19:05, 4 November 2020 (UTC)
Ideas related to this. Practical implementation could be that if the output rendered of the query.wikidata.org could read the PREFIX clauses of the query then users could define their own prefixes (already possible) which would be shortened in output in a same way than they are defined. In this way there is no need for pre-made server side configuration/knowledge at all. --Zache (talk) 06:11, 14 December 2020 (UTC)

Real life use case would be using embedded query-service in Wikipedia (w:fi:Malline:Linkitetty_data, screenshot). This is example made for this discussion. In generally using it in Wikipedia requires better output than it is possible in query service so the solution is to code custom renderer for the results which i would skip if possible.. --Zache (talk) 19:36, 5 November 2020 (UTC)

@Zache: We could investigate further to understand the general implications that this change will bring, but at the moment we do not see much community support for it. If that changes, then please feel free to bring it back to our attension. Thanks! -Mohammed Sadat (WMDE) (talk) 12:17, 10 November 2020 (UTC)
@Mohammed Sadat (WMDE): I added it to Community Wishlist as a proposal (m:Community_Wishlist_Survey_2021/Wikidata/Human_readable_wikilinks_to_Wikidata_query_service) so we can see if there is any community interest for it. --Zache (talk) 06:14, 28 November 2020 (UTC)
Okay, I will keep an eye on it. -Mohammed Sadat (WMDE) (talk) 09:14, 30 November 2020 (UTC)

Possible issue on lfn.wikipedia

Hello. Linking and displaying to Wikidata items seems to have an issue at lfn.wikipedia. I created lfn:Vicipedia:Dirijores today and tried to link it to Project:Administrators (Q4039395) using the sidebar option. For some reason that didn't work. I had to go to Project:Administrators (Q4039395) iself and add it from there (Special:Diff/1322297973); however interwiki links are still not displaying at that page though. Could you please take a look? Thank you. —MarcoAurelio (talk) 22:59, 13 December 2020 (UTC)

Steps to reproduce:
  1. Go to lfn:Vicipedia:Dirijores
  2. Attempt to use the sidebar link to link to a Wikidata item (use e.g. eswiki's Wikipedia:Bibliotecarios or enwiki's Wikipedia:Administrators
  3. Click "Link pages"
Result: an empty dialogue is offered and it is not possible to link that page with Project:Administrators (Q4039395)
I have provisionally removed the link so you could test this over lfn.wikipedia.
I created lfn:Vicipedia:Botes and in that case it let me link to the Wikidata item without issues though.
—MarcoAurelio (talk) 23:11, 13 December 2020 (UTC)
I can mostly reproduce the issue; the dialog isn’t empty (“page is already associated to an item; please confirm pages shown below”), but it shows no other pages and clicking “link with page” just generates JS errors (Uncaught TypeError: $(...).siteselector(...).getId is not a function). --Lucas Werkmeister (WMDE) (talk) 08:43, 14 December 2020 (UTC)
Thanks Lucas Werkmeister (WMDE). Indeed when I referred to "empty" I meant that it showed no other pages. In addition to the error above, there's also a jQuery.Deferred exception: Cannot read property 'getName' of null TypeError: Cannot read property 'getName' of null when selecting the page to link to. Shall I report to Phabricator or you or the dev team shall instead? Regards, —MarcoAurelio (talk) 11:21, 14 December 2020 (UTC)
For further debug: phab:P13543. —MarcoAurelio (talk) 11:41, 14 December 2020 (UTC)
LydiaPintscher seems to have fixed it somehow and now links display as well in lfn:Vicipedia:Dirijores. Thank you. I'm still curious about what happened and know, if possible, what to do if I encounter this issue in the future. Best regards, —MarcoAurelio (talk) 15:26, 14 December 2020 (UTC)

Large quantity values: difference between value stored and value displayed (13 November)

Tracked in Phabricator
Task T268456

Just notice that today: [1]. The full number is stored. --- Jura 07:13, 13 November 2020 (UTC)

It (still) works correctly at the largest one: Q67146010#P1181. Query for more. --- Jura 09:10, 14 November 2020 (UTC)
Hello Jura! Just so that I understand what we should be looking at, what do you see that is different from what you'd expect? -Mohammed Sadat (WMDE) (talk) 16:16, 17 November 2020 (UTC)
Entered/stored
68,636,564,122,675,662,743,823,714,992,884,378,001,308,422,399,791,648,446,212,449,933,215,410,614,414,642,667,938,213,644,208,420,192,054,999,687
Displayed
68,636,564,122,675,660,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

I'd expect that what is entered/stored is also displayed--- Jura 21:16, 18 November 2020 (UTC)

Okay, understood. Thanks! I've created a ticket so that we can look into it. -Mohammed Sadat (WMDE) (talk) 12:02, 23 November 2020 (UTC)
Thanks. Looks like the sample at Q67146010#P1181 is now borked too. Seems that some code change makes these display differently. --- Jura 14:16, 24 November 2020 (UTC)
Hi Jura! Thanks for your suggestions. Please avoid pinging multiple on the team about the same issue as that wouldn't necessarily get things done faster. If possible let's keep the discussion about the ticket on the ticket, or if you prefer, poke me here if there's anything you'd like us to know. -Mohammed Sadat (WMDE) (talk) 13:56, 15 December 2020 (UTC)
@Mohammed Sadat (WMDE): That's an odd way of saying I did what's needed. Or I just don't recall that I ever pinged someone on this before. Anyways, good to see it's finally moving ahead. --- Jura 18:30, 15 December 2020 (UTC)

Wiki data created Facebook checkin for our business page in Spanish

Hi can you please help, someone has created a check in for our business on Facebook which is linked to a wiki data page in Spanish this is very confusing as we are in Australia. Can you please hope us unlink this or make us the manager of this page so we can rename correctly and update relevant information? Thank you

  • This is the wrong venue. The Project Chat is a better address. Without saying which item you are concerned about, there's nothing that anybody can do to help you. There are no Wikidata pages in Spanish. Wikidata displays in the language you tell it to display. Wikidata pages have no managers. ChristianKl ❪✉❫ 12:41, 18 December 2020 (UTC)

Message about Rollback not working doesn't seem to be reliable

Earlier this day I was scrolling to a history page and accidently clicked on "rollback". Afterwards the page I visited told me that rollback wasn't successful so I thought there was no need to undo my accidental click. This seems to be a false assumption. ChristianKl ❪✉❫ 17:16, 15 December 2020 (UTC)

Do you mind making another test edit to confirm a successful/not successful rollback action? I'm not able to reproduce the issue without the rollbacker right. If this happens again or if someone else reports the same issue then I'll open a ticket, so we can look into it. Mohammed Sadat (WMDE) (talk) 11:00, 25 December 2020 (UTC)

True duplicates are no longer editable (August 29)

Tracked in Phabricator
Task T44325

DO NOT MERGE THE SAMPLE ITEMs.

Q96002185 can't be edited as the same enwiki sitelink is on Q96002184. I'm not sure if this is a step forward or backward from the previous situation. For some reason, it now leads to a crash of QuickStatements. How could this be improved? --- Jura 06:42, 29 August 2020 (UTC)

Other sample: Q97154094 (of Q97154095). --- Jura 05:21, 30 August 2020 (UTC)
Sample of today: Q97154088 and Q97154089 --- Jura 09:30, 13 September 2020 (UTC)
Hi Jura, I reread what you wrote but it is not clear to me what "leads to a crash of QuickStatements". Is it possible to reproduce this situation? Do you also mind explaining what you mean by "Q96002185 can't be edited as the same enwiki sitelink is on Q96002184". Thanks! -Mohammed Sadat (WMDE) (talk) 17:16, 16 October 2020 (UTC)


In the meantime, I merged the first two samples (after three weeks).
Q97154089 is still a true duplicate and can't be edited (even manually). --- Jura 18:31, 17 October 2020 (UTC)
@Jura1: We're currently working on fixing the root cause of this issue - the reason why two items happen to have the same sitelink. We prefer focussing our energy on fixing this issue rather than the symptom of it - the fact that true duplicates are not editable. We hope that the situation will happen less often, and we can indeed consider the fact that true duplicates are not editable as a feature. -Mohammed Sadat (WMDE) (talk) 16:45, 20 October 2020 (UTC)
What do you mean with "currently working"? Is someone this month actively looking into it and trying to complete it by end of November? --- Jura 18:45, 20 October 2020 (UTC)
We actually are not currently working on it. Sorry for the confusion. We are aware of the issue, and we have the task on our roadmap, but we don't have a precise timeline to make it happen. -Mohammed Sadat (WMDE) (talk) 11:29, 21 October 2020 (UTC)
Sounds good. Where can I see it on Wikidata:Development_plan? (I assume road map = development plan) --- Jura 10:17, 11 November 2020 (UTC)

Why does the documentation speak of a rank called RANK_TRUTH?

Tracked in Phabricator
Task T235871

According to https://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua#mw.wikibase.entity.claimRanks there's RANK_TRUTH in Wikidata but neither UI nor the Wikidata documentation speaks of such a rank. Does that rank get used somewhere? If not can we remove it? ChristianKl ❪✉❫ 11:26, 26 December 2020 (UTC)

RANK_TRUTH is the code for "best rank". The definition as quoted from the section mw:Extension:Wikibase Client/Lua#mw.wikibase.getBestStatements is 'The definition of "best" is that the function will return "preferred" statements, if there are any, otherwise "normal" ranked statements. It will never return "deprecated" statements.' These are also called "Truthy statements", e.g. in mw:Wikibase/Indexing/RDF Dump Format#Truthy statements. --Dipsacus fullonum (talk) 17:00, 26 December 2020 (UTC)
RANK_TRUTH is the code for "best rank". When you search code for the constant, you'll find only a few mentions. One of them:
  • Claim::RANK_TRUTH have been removed
implies this is likely a leftover. Maybe there is already a task for getting it removed (edit: it is). --Matěj Suchánek (talk) 18:13, 26 December 2020 (UTC)
Then it would make sense to be explicit in our documentation about it being deprecated and that it shouldn't be used moving forward? ChristianKl ❪✉❫ 12:54, 27 December 2020 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2020/12&oldid=1348315806"