Community Wishlist Survey 2021/Wikidata

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Community Wishlist Survey 2021
Wikidata
21 proposals, 319 contributors, 672 support votes
The survey has closed. Thanks for your participation :)



Improve Derived Statements

Edit proposal/discussion
  • Problem: at present, derived statements are shown only pressing a button at the bottom of the item. And the button itself is a preference (the relateditems gadget).
  • Who would benefit: increase the visibility of interconnections among items.
  • Proposed solution: add a section visible by default, compressed and expandable.
  • More comments: minimum information immediately shown in this section could depend on values of P31, and include counters at least. Expanding the section, all derived statements will become visible. Or other similar solution.
  • Phabricator tickets:
  • Proposer: Bargioni (talk) 09:29, 23 November 2020 (UTC)Reply[reply]

Discussion

Voting

Bibliographical references/sources for wikidataitems

Edit proposal/discussion
  • Problem:

Items (e.g. buildings, archeological sites, paintings, artists ...) described on various Wikimedia platforms benefit largely from good bibliographical sources. However, today one can only add such a source in an individual Wikipedia article (per language) and/or on a specific statement in Wikidata. As a result, many sources relevant for items/subjects remain hidden in all the languages of Wikipedia and knowledge remains "unused" and "undiscovered".

  • Who would benefit:

Editors on Wikipedia, the user community in general (more available sources = better articles) and all readers

  • Proposed solution:

The possibility to add a list of bibliographical references in a standard way, and data driven, (different from f.i. a list of works by a specific author) in a structured way per Wikidata-item. As a result, a list of bibliographical sources linked to the Wikipedia page via its corresponding Wikidata item would be automatically available in each language. For example, one could use this to link to historical sources/ archeological reports/ historic maps ... to for instance a town/artist/ ...

  • More comments: Advantages:
    1. More sources on Wikimedia platforms will be used
    2. More references per article add to the discussion as well as Wikipedia as a third source
    3. More data/research becomes visible through Wikimedia platforms and thus adds to its overall value within the information community
    4. Link between scientific research and valorisation of knowledge for a large scale audience through Wikipedia
  • Phabricator tickets:
  • Proposer: Hilke Arijs (talk) 17:15, 19 November 2020 (UTC)Reply[reply]

Discussion

  • I love this proposal. Wikidata has everything it requires. It is multi-lingual. You can register already today references described by source (P1343) to link an item e.g. to a book/edition. The only thing that is required is a Wikidata module for Wikipedia to extract a bibliography from Wikidata. Geert Van Pamel (WMBE) (talk) 17:49, 19 November 2020 (UTC)Reply[reply]
  • @Hilke Arijs: While in principle this proposal would improve Wikidata items, I feel like the proposal suffers from a lack of clarity, and it's not clear whether you're proposing a technical change that would somehow enable this or a comprehensive import that would actually allow this to be useful in the short term (at the moment, there's not enough relevant Wikidata data for such a feature to be genuinely useful). There are already properties that exist to relate works and subjects (main subject (P921) and described by source (P1343)), and there are already modules which allow data from multiple statements to be extracted (Commons' Wikidata infobox already does it). Either way, the proposal could be fulfilled without any changes to the underlying software, so it's possible that this wouldn't be within the survey's scope to begin with. Jc86035 (talk) 19:08, 20 November 2020 (UTC)Reply[reply]
  • Could also be related to/benefit from mw:Global templates. Geert Van Pamel (WMBE) (talk) 11:08, 21 November 2020 (UTC)Reply[reply]
  • Actually, it could be implemented as an option, like we currently have with Wdsearch. Geert Van Pamel (WMBE) (talk) 11:08, 21 November 2020 (UTC)Reply[reply]
  • We could first do two simple things:
    • copy a (structured) reference from a wiki to wikidata
    • use this multiple times in the wikidata item for the properties it refers to.
Example: We have most info about person from ref1. Then we can use ref1 for the person's name, profession, place and date of birth, nationality, family. It would be enough to fill in ref1 as reference and ref1 to be a nicely formatted, full reference, copied from the wiki. Now we can only do that by leaving a simple URL multiple times (or filling in several source fields in every property, again and again). --FocalPoint (talk) 06:37, 24 November 2020 (UTC)Reply[reply]
You can edit once the reference and then copy-paste the whole reference data to each relevant statement using DuplicateReferences gadget. Any reference structure has to take account the possibility to retrieve data for one statement. Having a kind of redirection of the reference is a dangerous tool unless it is well built to be automatically updated. Just take the case where the reference is deleted and not the redirections ? From my point of view this will generate more problems. Snipre (talk) 08:29, 24 November 2020 (UTC)Reply[reply]
  • The proposal is not well described from technical point of view: this is 2 possibilities from my opinion. The first is to create like for WP article a bibiography property liking an item to the reference item, and th second is to create some kind of key word property allowing to link each reference item to some topic. Then an extraction tool can do the data extraction and recreate the bibliography. No need of a tool for that, just some good knowledge of the API tool. Snipre (talk) 08:33, 24 November 2020 (UTC)Reply[reply]
  • One option has already been implemented for several languages, automatically listing the Wikidata identifiers related to the subject, by including the template w:Authority control, w:nl:Template:Bibliografische informatie, etc. at the bottom of the article, just before the category list. Geert Van Pamel (WMBE) (talk) 20:32, 13 December 2020 (UTC)Reply[reply]
  • I believe this is just what the WikiCite project is already doing? Geert Van Pamel (WMBE) (talk) 21:35, 16 August 2022 (UTC)Reply[reply]

Voting

Edit Wikidata in a map!

Edit proposal/discussion
  • Problem: Wikidata are great, but editing them requires still quite some knowledge of stuff like SPARQL etc. This makes the whole project less accessible to others. Everyone knows a map. Why can't we just fork a tool like Wikishootme so the users could edit the items directly in a map? Sure, not all items are geography-related but many are. Wikishootme is great for adding images. Now imagine that instead of adding images we could add other data.
  • Who would benefit: Wikidata community, Wikidata newbies.
  • Proposed solution: Forking Wikishootme and making it more versatile. Using the concept of adding a string to P18 in a window in the map for other properties.
  • More comments:
  • Phabricator tickets:
  • Proposer: Aktron (talk) 10:50, 17 November 2020 (UTC)Reply[reply]

Discussion

  • Just daydreaming here, but it would be awesome to have a fork of the OSM iD editor that would allow editing OSM and Wikidata simultaneously. NMaia (talk) 03:30, 18 November 2020 (UTC)Reply[reply]
    Now we're cooking with fire. --Izno (talk) 05:18, 18 November 2020 (UTC)Reply[reply]
    Great idea! Watty62 (talk) 14:35, 11 December 2020 (UTC)Reply[reply]
  • First step should be "create item here", which automatically fills coordinates, country and asks for P31, P18 etc.
    • Second step should be connecting with shapes on commons and automatically filling P131
    • Every item with coordinates should have P31, P18, P131, P373... JAn Dudík (talk) 15:06, 18 November 2020 (UTC)Reply[reply]
    • Well yes. Wikishootme can create an item from the map – and that is a very good start! But everything else has to be inserted in Wikidata and that kinda breaks the process. The first step just makes a blank item with coordinates only. We should move further than that. Aktron (talk) 15:24, 21 November 2020 (UTC)Reply[reply]
  • I like this splendid idea. Reverse the application logic: start from a map to create and populate an item, instead of clumsily searching an item, and manually adding coordinates as a property of an item via copy/paste of geocoordinates. Only (major) problem: the tool should properly identify if an item does not exist, or does not have yet coordinates (P625) in order to avoid duplicates. Geert Van Pamel (WMBE) (talk) 14:37, 19 November 2020 (UTC)Reply[reply]
      • But then again if you'd see the item on the map ＡＬＲＥＡＤＹ then you'd most likely avoid making a duplicate one. So another point for a map editor! Aktron (talk) 15:24, 21 November 2020 (UTC)Reply[reply]
  • I like this daydream ;) but: a nightmare would be easily done vandalizm and controlling that could be quite difficult I imagine... Of course only one thing could help a bit: people wanting to edit via map should have accounts both on OSM AND Wikidata/Wikipedia. --katpatuka (talk) 05:01, 21 November 2020 (UTC)Reply[reply]
  • Addition: there are lots of places in osm lacking wikidata tag and the same places in WD lacking coordinates! In OSM's josm editor there's the wikipedia plugin which simplifies linking OSM objects to WD/WP data - so a sort of inverse synchronization tool/gadget for WD simplifying linking WD objects to OSM objects would be really useful --katpatuka (talk) 05:31, 21 November 2020 (UTC)Reply[reply]
  • Sounds good! Maybe there's a connection to the Wikidata Bridge project. There are definitely a lot of Wikidata items that still need coordinates adding to them, though, e.g., commons:Category:Uses of Wikidata Infobox with no coordinate... Thanks. Mike Peel (talk) 13:45, 3 December 2020 (UTC)Reply[reply]

Voting

Link Wikipedia redirects to Wikidata items

Edit proposal/discussion
  • Problem: Wikipedia redirects cannot be linked to Wikidata items
  • Who would benefit: Mainly Wikidata users seeking relevant Wikipedia text
  • Proposed solution: In the Wikidata UI, allow Wikipedia redirects to be linked to items
  • More comments: Some Wikipedia redirects already link to Wikidata items. For example, en:517 BC correctly links to d:Q715545. However, Wikidata's UI prevents the creation of such useful links. To create it, one must first make a "bad" edit to Wikipedia, replacing the redirect by a dummy article, then link to that "article" in Wikidata, then self-revert on Wikipedia to restore the redirect.
  • Phabricator tickets:
  • Proposer: Certes (talk) 02:14, 23 November 2020 (UTC)Reply[reply]

Discussion

I was going to say that I proposed this already here: Community_Wishlist_Survey_2015/Wikidata, but I misread your problem, which is also known as the "Bonnie and Clyde problem", and is explained in detail at d:Help:Handling sitelinks overlapping multiple items. My proposal wasn't to change Wikidata UI, but to change the Wikipedia UI in the way redirects are implemented on the Wikipedia side, so instead of #REDIRECT [[Target]] you would see something like #REDIRECT [[d:Qid|Target]] where the Qid is optional for the redirect (most redirects for Q5 items are alternate spellings and don't need any alternate than the direct local target). Your work-around to create it is a known kludge to get around the Bonnie & Clyde problem which I delete when I see them because they could be created by people like you or because articles get deleted sometimes. I delete them because they gum up my Sparql results. Jane023 (talk) 11:18, 29 November 2020 (UTC)Reply[reply]

Editors create these links to help Wikidata. If you are deleting them because they are unwelcome, just let us know, and we'll stop creating them and I'll withdraw (or at least not support) this proposal. Certes (talk) 21:45, 8 December 2020 (UTC)Reply[reply]
@Jane023: Once this is implemented, it should be possible to exclude redirects from Sparql results, as they will have an associated badge (See T235420). So instead of having a kludge that messes up query results (as you do now), you would have a proper implementation that alleviates your problem. In other words, you would be able to choose whether or not to include redirects in query results, which you can't do currently, AFAIK. Kaldari (talk) 03:16, 9 December 2020 (UTC)Reply[reply]

Does this finally mean that an English language Wikipedia entry (c|w)ould show multiple Inter-wikilinks (the version created from Wikidata that is) from another language. Shyamal (talk) 08:17, 9 December 2020 (UTC)Reply[reply]

@Shyamal: This would make most manual Inter-Wikilinks unnecessary. There are still some cases where individual Wikipedia's have policies that make certain redirects not welcome. ChristianKl ❪✉❫ 11:47, 9 December 2020 (UTC)Reply[reply]
@ChristianKl: - I was not clear, not manual interwikis of course - but now that a language A Wikipedia entry may be covered by two entries in language B (linked via two Wikidata items), how does the Wikipedia entry guide a reader from language A to two possible page in B (I am assuming the side bar will ideally have multiple targets under language B when one sees the language A entry). Shyamal (here is a case in question - the Korean entry at https://ko.wikipedia.org/wiki/%EB%8F%99%EA%B3%A8%ED%95%B4%EB%A9%B4%EB%AA%A9 d:Q139079 does not have a interlanguage to the English version or vice versa because the English entry is covered under https://en.wikipedia.org/wiki/Homosclerophorida d:Q13140211 - adding the redirect in Wikidata is one aspect, but how would it get interpreted on the Wikipedia sidebar? I presume the priority would be to be able to guide the ease of user navigation between KO and EN) (talk) 11:53, 9 December 2020 (UTC)Reply[reply]
This feature alone doesn't provide a way to guide users from A to two possible B (B1 and B2. A Wikipedia that hosts B1 and B2 and that wants that people from A can come to B could create a bot that automatically creates pages that say "A is covered in B1 and B2" and then add a sitelink from the A to that new page.
Whether or not bots that create such pages are seen as desirable by individual Wikipedia communities will be seen. In case they aren't it's also possible to create a gadget that has some virutal form of those B1 or B2-pages.
This feature will mean that the data that a bot that creates those B1 or B2-pages or a gadget would need exist. ChristianKl ❪✉❫ 12:48, 9 December 2020 (UTC)Reply[reply]
This feature would help us to guide readers from language B to language A (e.g. from article nl:Bonnie Parker to redirect en:Bonnie Parker which targets the section en:Bonnie and Clyde#Bonnie Parker). It neither helps nor hinders the 1→many link from language A to language B. Certes (talk) 13:01, 9 December 2020 (UTC)Reply[reply]
Some canvassing happened at d:Wikidata:Project_chat#Finally_fixing_the_Bonnie_and_Clyde_problem. I still oppose this change because it would break the current data model in regard to uniqueness. I'm sure more people Oppose Oppose this change, but I guess these pages are just to cheer on proposals. Multichill (talk) 22:37, 9 December 2020 (UTC)Reply[reply]
@Multichill: the uniqueness of the data model gets defined via the notability policy and the sitelinks to redirects change nothing about notability. ChristianKl ❪✉❫ 01:16, 11 December 2020 (UTC)Reply[reply]
@Multichill: Isn't that a data model that very much needs to be broken? What is the down side of breaking it? Kaldari (talk) 20:17, 15 December 2020 (UTC)Reply[reply]
There was an RFC in 2018 with majority support for allowing links to redirects, but action on the phab ticket to improve the UI stalled, as the devs wanted to consider other options despite consensus. Solution involves badging the sitelinks to redirects so that they can be filtered in queries (as Kaldari noted above), and templating the redirect pages to flag them as intentional (the latter practice is already happening on English Wikipedia). Sorry I don't have the links on hand but will try to find them. Pelagic (talk) 17:33, 15 December 2020 (UTC)Reply[reply]
Here is the RFC I was thinking of: d:Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata. —Pelagic (talk) 18:27, 15 December 2020 (UTC)Reply[reply]
On the data abstraction: redirect pages are still mediawiki pages, and they are in the main namespace, just like articles. This URI https://en.wikipedia.org/w/index.php?title=Bonnie_Parker&redirect=no is still "schema:about" Bonnie Parker, even though its content is an instruction to visit the section of another page. Traditional printed encyclopaedias have see entries in their indices for a reason. What I hope for is, when adding a sitelink in the UI and selecting a redirect, to get the choice to either add the redirect itself (where it links to a section or is semantically distinct from its target) or the redirect-target (redirect for misspelling or alternate name). This URI https://en.wikipedia.org/wiki/Bonnie_and_Clyde#Bonnie_Parker is also schema:about Bonnie Parker. If you don't want to allow sitelinks to redirects, then allow them to article sections. In both cases you are stretching the expectation that sitelinks point to articles: either extend it in one direction to include main-namespace non-article pages, or in the other direction to include sections of articles. Either way the reader should be able to navigate from an article in one language to a section of an article in another language, where the former and latter are both about the same subject. We already have sitelinks to non-mainspace non-article pages, even though w:en:WP:Village Pump isn't about d:Q16503, it's an instance of Q16503. The primary point of sitelinks isn't the RDF or the semantics, it's to allow users to move between related content. Pelagic (talk) 18:19, 15 December 2020 (UTC)Reply[reply]

Voting

Time and date handling improvements

Edit proposal/discussion
  • Problem: Dealing with time and dates on Wikidata is a long-standing problem, with several aspects that usually are brought forward to discuss. This is an attempt to summarise the most pressing aspects, by selecting the relevant Phabricator tickets and checking all previous Community wishlist requests:
  1. allowing time values more precise than "day" (task T57755) - this is a recurring request that dates back to October 15, 2013 to have a potential time precision up to seconds, and not limited just to days;
  2. supporting non-Gregorian/Julian calendars (task T252627) - this is another non-trivial request for handling sources that express dates and occurrences in calendars other than Gregorian and Julian;
  3. fixing annoying problems with displaying date values (task T63958 and task T95553) – pretty self-explanatory, mostly related to a better localisation of values, that nonetheless is needed.
These are the main three aspects, though many other things might be needed to be looked at. Our common hope is to find finally someone who can tackle those problems.
  • Who would benefit: primarily Wikidata contributors, but also Wikidata re-users at large
  • Proposed solution: add functionalities and fix current problems in this field
  • More comments:
  • Phabricator tickets:
    • task T57755 – Allow time values more precise than day on Wikidata
    • task T63958 – Use existing $dateFormats to format dates on Wikidata
    • task T95553 – Full stop in messages such as Wikibase-time-precision-century is incorrect in English
    • task T252627 – Support for additional calendar models
  • Proposer: Sannita - not just another it.wiki sysop 13:56, 18 November 2020 (UTC)Reply[reply]

Discussion

Voting

Support ISO 8601-2:2019 to specify uncertainty about times

Edit proposal/discussion
  • Problem: Many times sources specify a date with some uncertainty. A source might say that a person died between 1341 and 1345, or that it was approximately created at a certain date.
  • Who would benefit: Anyone who wants to record data with uncertainty in a way similar to what the sources say.
  • Proposed solution: Adopt the ways of specifying Time Interval, Qualification of a date and Unspecified digit(s) from the right layed out in ISO 8601-2:2019 (described in http://www.loc.gov/standards/datetime/edtf.html). This would allow writing 1341/1345 for a date of death between 1341 and 1345.
  • More comments:
  • Phabricator tickets: https://phabricator.wikimedia.org/T207705
  • Proposer: ChristianKl ❪✉❫ 21:33, 17 November 2020 (UTC)Reply[reply]

Discussion

  • Sounds sensible. Does the standard also cover some typical historical usages (fl., circa, before X...)? I tend to see that kind of dating are usually misunderstood for more numerical treatment.--FAR (talk) 12:18, 28 November 2020 (UTC)Reply[reply]
    • As far as I understand fl. stands for floruit and that's well modeled as it's own property in Wikidata and I don't see how it belongs here. The standard defines "uncertain" and "approximate". Circa can be modeled with uncertain. I didn't explicitly ask for open ended time intervals in this proposal but the standard does define them. ChristianKl ❪✉❫ 23:03, 15 December 2020 (UTC)Reply[reply]
  • +1 to Jarekt below: While the current practice is tedious and I don’t like it very much, a clear path to a clean future unified state would need to be defined prior to implementing the proposal. --Mormegil (cs) 14:08, 14 December 2020 (UTC)Reply[reply]
    • Yes, but the Community Wishlist is not the place to define standards of how things are used. Those conversation have to happen on Wikidata and having them only makes sense when there's a decent likelihood that there's work on this feature. ChristianKl ❪✉❫ 22:58, 15 December 2020 (UTC)Reply[reply]
  • EDTF support is now available for Wikibase via the Wikibase EDTF extension. (Release announcement, Demo video) --Jeroen De Dauw (talk) 12:44, 26 April 2021 (UTC)Reply[reply]

Voting

sort statements as you wish

Edit proposal/discussion
  • Problem: Sometimes, users want to check on a larger number of items whether these already have the Pid statement. Example: It can be very annoying to look up whether a given human (Q5) already has a religion or occupation statement; these would be somewhere down there between a lot of other statements…
  • Who would benefit: anyone who edits Wikidata
  • Proposed solution: It would be very useful to have some statement – chosen by you! – right above when you open the page of an item (perhaps right below an instance of statement). Or even sort the statements freely.
  • More comments:
  • Phabricator tickets:
  • Proposer: Geogast (talk) 17:19, 23 November 2020 (UTC)Reply[reply]

Discussion

It's a good idea but did you know that you can go directly to a statement using the following url path Qid#Pid : Wikidata:Q2826599#P3206? PAC2 (talk) 17:42, 23 November 2020 (UTC)Reply[reply]

In fact, I didn't. Thanks for this! But it would love a more practical approach than writing #Pid in the URL every time.--Geogast (talk) 18:59, 23 November 2020 (UTC)Reply[reply]
If users are coming from an external site (ie. Wikipedia) the anchor linking to the middle of the page is very confusing. It would be better if the anchored property would be at the top of the page so there would be context AND you could select multiple properties to be grouped to the top. (example code: Wikidata:User:Zache/vector.js and link Wikidata:Q2826599#P17,P571). --Zache (talk) 18:52, 27 November 2020 (UTC)Reply[reply]
Yes, that was my idea: The anchored properties go to the top. And: You choose the properties (opt-in); anyone who doesn't need this feature won't use it and won't get confused.--Geogast (talk) 18:44, 30 November 2020 (UTC)Reply[reply]

Voting

Extend Gadget - Drag'n'drop

Edit proposal/discussion
  • Problem: Drag'n'drop is a great gadget that transports statements from Wikipedia to Wikidata with a simple drag and drop. It would also be nice if you could use this method for "commons" as well, to quickly insert images.
  • Who would benefit: Everyone who uses it
  • Proposed solution: Expansion of this gadget
  • More comments:
  • Phabricator tickets:
  • Proposer: Crazy1880 (talk) 18:21, 25 November 2020 (UTC)Reply[reply]

Discussion

You can check my rewrite of this gadget I did some time ago, add importScript('User:Yarl/DragNDrop.js') to your /common.js subpage. Yarl (talk) 14:36, 14 December 2020 (UTC)Reply[reply]

Voting

Slow and fast edits

Edit proposal/discussion

Discussion

Voting

  • Support Support Sounds easy enough to implement. Also easy to game, but it would lift the bar. Can you run some numbers on potential impact? Dagelf (talk) 08:14, 9 December 2020 (UTC)Reply[reply]
  • Support Support Jcwang1986 (talk) 08:56, 9 December 2020 (UTC)Reply[reply]
  • Oppose Oppose (to make a remark here); "unimportant" is a highly subjective classification; I think we should not even try to rate edits or user activity for their "importance" as this might easily alienate those whose edits are found to be "unimportant". —MisterSynergy (talk) 09:01, 9 December 2020 (UTC)Reply[reply]
  • Support Support MisterSynergy, I think this is supposed to be a thing people decide for themselves when they start their batch--"my batch can go slow" Abductive (talk) 09:18, 9 December 2020 (UTC)Reply[reply]
  • Support Support Thomas Kinz (talk) 21:34, 9 December 2020 (UTC)Reply[reply]
  • Oppose Oppose - This proposal is far too broad and not properly worked out. Husky (talk) 16:16, 11 December 2020 (UTC)Reply[reply]
  • Support Support should be doable using in example with tags and it would work as hint for WQS updater that which updates can be batch update later. --Zache (talk) 19:00, 11 December 2020 (UTC)Reply[reply]
  • Oppose Oppose - less is more many times small edits may be important and so underestimated: see MisterSynergy's comment as well, Klaas `Z4␟` V:  14:58, 12 December 2020 (UTC)Reply[reply]
  • Oppose Oppose --Jarekt (talk) 15:20, 12 December 2020 (UTC)Reply[reply]
  • Support Support Kartsriv (talk) 17:24, 19 December 2020 (UTC)Reply[reply]

Duplicates and merge candidates

Edit proposal/discussion
  • Problem: There is an increasing number of items that are empty or possible duplicates
  • Who would benefit: Wikidata editors
  • Proposed solution: Improve on prior art like Projectmerge to detect duplicates not only by labels but by comparing properties and links with other items; migrate the WD:DNM do not merge lists to something more usable (example suggested in the discussion page, migrate to P1889 statements
  • More comments:
  • Phabricator tickets:
  • Proposer: Sabas88 (talk) 12:38, 20 November 2020 (UTC)Reply[reply]

Discussion

  • Removed the Phabricator task as it's not relevant. --Matěj Suchánek (talk) 15:54, 20 November 2020 (UTC)Reply[reply]
  • @Sabas88: Thanks for your proposal. Is there code for the mentioned projects that we can take a look at? We'd like to have a better understanding on how the projects detect duplicates. Thanks again! Harumi Monroy 19:35, 23 November 2020 (UTC)Reply[reply]
    Sorry I can't find it... Help:Merge has a list of tools but I didn't see a relevant git repository --Sabas88 (talk) 12:45, 25 November 2020 (UTC)Reply[reply]
  • A good idea. Improve on existing tools, to be able to better predict if two items are duplicate. Simplistic example: same name, different description, but both populated places (or similar property, city, village) with a very similar geographic location (within a radius of 2 km one from the other). --FocalPoint (talk) 05:58, 24 November 2020 (UTC)Reply[reply]
    Or if not same name, perhaps with some other String Metric and comparing properties..--Sabas88 (talk) 12:45, 25 November 2020 (UTC)Reply[reply]

Voting

Expand automatic edit summaries

Edit proposal/discussion
  • Problem: When one't watchlist is set to display edits made on linked statements on Wikidata, they are always displayed in numerical code even if labels exist on the Wikidata entries. For example, this diff on enWikipedia's watchlist displays as "Created claim: Property:P4552: Q5456; Added reference to claim: Property:P4552: Q5456" whereas on Wikidata it's two diffs with two edit summaries, "Added reference to claim: mountain range (P4552): Andes (Q5456)" and "Created claim: mountain range (P4552): Andes (Q5456)".
  • Who would benefit: People who use their watchlist on a non-Wikidata project to monitor changes to the Wikidata item linked to an article they have watchlisted. On enWikipedia some templates draw information from Wikidata so making it easy to monitor the edit content may be beneficial.
  • Proposed solution: The watchlist should display the language label if it does exist in lieu of the numerical code; in this case the summary should be "Created claim: Property:mountain range: Andes; Added reference to claim: Property:mountain range: Andes" perhaps with the "property" omitted if it makes the summary overlong.
  • More comments: I hope I didn't send this - which is a re-do of two previous proposals among the same lines - in too late.
  • Phabricator tickets: phab:T108688; phab:T171027 may be worth paying attention to since it's a technical issue that could impact on this project.
  • Proposer: Jo-Jo Eumerus (talk, contributions) 09:46, 29 November 2020 (UTC)Reply[reply]

Discussion

Voting

Anti-vandalism tools for Wikidata

Edit proposal/discussion
  • Problem: Wikidata has a lot of vandalism and the tools to fight it are not very good.
  • Who would benefit: Admins, all wikis that use Wikidata
  • Proposed solution: Develop tools to fight vandalism. A start would be w:en:WP:TWINKLE, to automate reverting, warning a user, blocking, and leaving the right templated messages in all those cases. Then we could also get something like w:en:WP:HUGGLE to load changes in real time and get them patrolled.
  • More comments: This will attract an army of editors to fight vandalism on Wikidata, similar to English Wikipedia. This will improve trust in Wikidata.
  • Phabricator tickets:
  • Proposer: Rschen7754 01:57, 17 November 2020 (UTC)Reply[reply]

Discussion

  • Note that there is currently a ticket for Huggle (T183141) marked high-priority for (at least partial) support of Wikidata. Courtesy ping since they authored said ticket: Petrb. Perryprog (talk) 02:39, 17 November 2020 (UTC)Reply[reply]
  • Yes, this is needed so badly. {{u|Sdkb}} talk 02:43, 17 November 2020 (UTC)Reply[reply]
  • There are some bugs with issuing warnings, but otherwise Huggle seems to work mostly OK for me... I always keep Wikidata in my feed alongside English Wikipedia. My only real complaint is phab:T199500, which is actually a big problem, but all things considered using Huggle is still more efficient than Special:RecentChanges. As for Twinkle, the first step to get the UI localized. That's in progress now and slated to be completed by the end of the year. — MusikAnimal talk 02:57, 17 November 2020 (UTC)Reply[reply]
  • There is also the fact that recreations are a lot harder to track due to them being at new entity ids instead of at the same title, so title blacklisting or creation protection isn't available... --DannyS712 (talk) 03:27, 17 November 2020 (UTC)Reply[reply]
  • Nice idea, yes we do need twinkle like tool which will work on wikidata, actually modifying global twinkle would be an good idea? to fit in requirements of Wikidata, commons, wikisource? QueerEcofeminist [they/them/their] 05:40, 18 November 2020 (UTC)Reply[reply]
  • This is an important proposal, but I do not think that Huggle and Twinkle can be made particularly useful for Wikidata RC patrolling. Those tools let us basically make ad-hoc revision-based assessments, but we rather need tools for a much more user-based patrolling process. In other words: the question usually is whether a given user generally makes good faith edits (and to a lesser degree has the skills to get it right), rather than whether a particular edit was made with good faith.
    Modifications in Wikidata are often composed of several “atomic” edits (i.e. a collection of edits that are usually close to a smallest possible increment); it is often not useful to look at individual edits (diffs) in particular, as only the overall picture tells us the full story. This is even more important in situations involving more than one item (sitelink moves, mergers, etc.).
    Another key feature for Wikidata patrolling are editorial filter options, so that the patroller can efficiently filter edits of a certain type of modification (e.g. limited to a specific language or property). There are some tools out there doing exactly this, but improvements are certainly possible. —MisterSynergy (talk) 09:20, 18 November 2020 (UTC)Reply[reply]
  • Since more and more wikis rely on Wikidata, it's fundamental to protect the integrity of the information in it. --Andyrom75 (talk) 22:12, 20 November 2020 (UTC)Reply[reply]
  • I know this proposal is vague but I think that is okay. More than any particular vandalism tool, we just need any vandalism tool so that we can encourage more discussion about what kind of vandalism Wikidata experiences and how we prepare a long term effort to counter it. This works as an open proposal - just start with the technical development of any vandalism tools on Wikidata. Blue Rasberry (talk) 18:17, 24 November 2020 (UTC)