Community Wishlist Survey 2021/Wikidata

Wikidata
21 proposals, 319 contributors, 672 support votes
The survey has closed. Thanks for your participation :)



Improve Derived Statements

  • 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)

Discussion

Voting

Bibliographical references/sources for wikidataitems

  • 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)

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)
  • @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)
  • Could also be related to/benefit from mw:Global templates. Geert Van Pamel (WMBE) (talk) 11:08, 21 November 2020 (UTC)
  • 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)
  • 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)
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)
  • 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)
  • 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)

Voting

  •   Support Geert Van Pamel (WMBE) (talk) 19:09, 8 December 2020 (UTC)
  •   Support Imz (talk) 20:10, 8 December 2020 (UTC)
  •   Support Ssstela (talk) 21:30, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 22:26, 8 December 2020 (UTC)
  •   Support NMaia (talk) 03:07, 9 December 2020 (UTC)
  •   Support This sounds like a great idea that would help unify Wikipedia and Wikidata. Scholars and casual users alike could see what are considered to be the definitive references on certain topics in different languages. It would be even more useful if works in one language were linked to their currently available translations in other languages. Ottawajin (talk) 05:41, 9 December 2020 (UTC)
  •   Support For all the good reasons mentioned above Paul Hermans 08:19, 9 December 2020 (UTC)
  •   Support Kpjas (talk) 11:20, 9 December 2020 (UTC)
  •   Support DaSupremo (talk) 16:37, 9 December 2020 (UTC)
  •   Support Lirazelf (talk) 17:15, 9 December 2020 (UTC)
  •   Support - Darwin Ahoy! 01:57, 10 December 2020 (UTC)
  •   Support Watty62 (talk) 14:46, 11 December 2020 (UTC)
  •   Support Susanna Giaccai (talk) 16:48, 11 December 2020 (UTC)
  •   Support not only bibliographical, but useful for webSources as well  Klaas `Z4␟` V:  15:39, 12 December 2020 (UTC)
  •   Support. Meiræ 21:56, 12 December 2020 (UTC)
  •   Support ViktorQT (talk) 13:55, 14 December 2020 (UTC)
  •   Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:46, 15 December 2020 (UTC)
  •   Support Kku (talk) 07:25, 17 December 2020 (UTC)
  •   Support AdaHephais (talk) 05:42, 20 December 2020 (UTC)
  •   Support S8321414 (talk) 14:40, 21 December 2020 (UTC)

Edit Wikidata in a map!

  • 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)

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)
    Now we're cooking with fire. --Izno (talk) 05:18, 18 November 2020 (UTC)
    Great idea! Watty62 (talk) 14:35, 11 December 2020 (UTC)
  • 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)
    • 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)
  • 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)
      • But then again if you'd see the item on the map ALREADY 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)
  • 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)
  • 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)
  • 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)

Voting

Link Wikipedia redirects to Wikidata items

  • 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)

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)

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)
@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)

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)

@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)
@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)
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)
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)
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 this change, but I guess these pages are just to cheer on proposals. Multichill (talk) 22:37, 9 December 2020 (UTC)
@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)
@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)
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)
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)
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)

Voting

  •   Support Sometimes articles on one wiki are covered as part of another article in another wiki; Wikidata connection through a redirect would be a good interim fix. Jo-Jo Eumerus (talk, contributions) 18:36, 8 December 2020 (UTC)
  •   Support This would bring Wikidata inline with how Wikipedia thinks of redirects. IagoQnsi (talk) 18:38, 8 December 2020 (UTC)
  •   Support Imz (talk) 20:06, 8 December 2020 (UTC)
  •   Support Berdajeno (talk) 20:37, 8 December 2020 (UTC)
  •   Support Tcit (talk) 21:29, 8 December 2020 (UTC)
  •   Support Pi.1415926535 (talk) 21:29, 8 December 2020 (UTC)
  •   Support Epìdosis 21:35, 8 December 2020 (UTC)
  •   Support Nw520 (talk) 22:51, 8 December 2020 (UTC)
  •   Support I hope it would be useful for my problems RXerself (talk) 00:09, 9 December 2020 (UTC)
  •   Support 5225C (talkcontributions) 00:19, 9 December 2020 (UTC)
  •   Support--Alexmar983 (talk) 01:19, 9 December 2020 (UTC)
  •   Support Kaldari (talk) 02:55, 9 December 2020 (UTC)
  •   Support Shyamal (talk) 03:37, 9 December 2020 (UTC)
  •   Support {{u|Sdkb}}talk 04:09, 9 December 2020 (UTC)
  •   Support probably huge step toward better Wiki-world. If very negative and unpredictable consequences will arise, it is easy to pause/stop this new approach--Estopedist1 (talk) 07:20, 9 December 2020 (UTC)
  •   Support Obvious support, there is no downside to this that I can see MSGJ (talk) 08:41, 9 December 2020 (UTC)
  •   Support I wrote a policy page that lays out how we will use the badges to tag redirect in Wikidata and clarified remaining ambiguities. This is likely the more direct way to get change. The RfC is at https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Adopt_Help:SitelinksToRedirects_as_policy ChristianKl❫ 11:11, 9 December 2020 (UTC)
  •   Support Kpjas (talk) 11:23, 9 December 2020 (UTC)
  •   Support ArthurPSmith (talk) 15:56, 9 December 2020 (UTC)
  •   Support Nehaoua (talk) 16:40, 9 December 2020 (UTC)
  •   Support. Simon Cobb (Sic19 ; talk page) 18:04, 9 December 2020 (UTC)
  •   Supportputnik 19:28, 9 December 2020 (UTC)
  •   Support JAn Dudík (talk) 20:30, 9 December 2020 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 9 December 2020 (UTC)
  •   Support Mike Peel (talk) 20:45, 9 December 2020 (UTC)
  •   Support Ecritures (talk) 21:58, 9 December 2020 (UTC)
  •   Support Moebeus (talk) 22:05, 9 December 2020 (UTC)
  •   Support crazy idea, makes sense Blue Rasberry (talk) 01:42, 10 December 2020 (UTC)
  •   Support - Darwin Ahoy! 01:56, 10 December 2020 (UTC)
  •   Support Efly (talk) 10:40, 10 December 2020 (UTC)
  •   Support - Valentina.Anitnelav (talk) 12:06, 10 December 2020 (UTC)
  •   Support Dexxor (talk) 16:44, 10 December 2020 (UTC)
  •   Support Evad37 (talk) 09:08, 11 December 2020 (UTC)
  •   Support Dhx1 (talk) 12:54, 11 December 2020 (UTC)
  •   Support Watty62 (talk) 14:47, 11 December 2020 (UTC)
  •   Support Jc86035 (talk) 16:24, 11 December 2020 (UTC)
  •   Support Susanna Giaccai (talk) 16:53, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 18:29, 11 December 2020 (UTC)
  •   Support --Kusurija (talk) 18:44, 11 December 2020 (UTC)
  •   Support Stevenliuyi (talk) 22:14, 11 December 2020 (UTC)
  •   Support Loopy30 (talk) 23:32, 11 December 2020 (UTC)
  •   Support --Alaa :)..! 01:27, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:25, 12 December 2020 (UTC)
  •   Support. Meiræ 22:02, 12 December 2020 (UTC)
  •   Support NoInkling (talk) 01:17, 13 December 2020 (UTC)
  •   Support Shushugah (talk) 21:42, 13 December 2020 (UTC)
  •   Support Yes please. This would solve a quite annoying problem which has made Wikidata essentially unsuitable for managing interwiki links.   hugarheimur 08:53, 14 December 2020 (UTC)
  •   Support Michel Bakni (talk) 14:01, 14 December 2020 (UTC)
  •   Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:44, 15 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 13:57, 15 December 2020 (UTC)
  •   Support SeGiba (talk) 18:05, 15 December 2020 (UTC)
  •   Support. Make interlanguage links great again. Pelagic (talk) 18:24, 15 December 2020 (UTC)
  •   Support Incidentally, including the redirect of helpful resources, e.g. Wikipedia:RSP to Wikidata for P854 (reference URL) check. ShiehJ (talk) 20:56, 15 December 2020 (UTC)
  •   Support Tilon3 (talk) 06:42, 16 December 2020 (UTC)
  •   Support Katzmann83 (talk) 14:25, 16 December 2020 (UTC)
  •   Support --Luan (discussão) 19:50, 16 December 2020 (UTC)
  •   Support I held back in case the proposal would gum up Sparql results, but that no longer seems to be a problem. Certes (talk) 22:19, 16 December 2020 (UTC)
  •   Support Gdafs (talk) 15:05, 17 December 2020 (UTC)
  •   Support Waiting for this since years Ameisenigel (talk) 15:43, 17 December 2020 (UTC)
  •   Support Jklamo (talk) 16:21, 19 December 2020 (UTC)
  •   Support AdaHephais (talk) 05:46, 20 December 2020 (UTC)
  •   Support Fringilla (talk) 19:55, 20 December 2020 (UTC)
  •   Support Not sure how to implement is the best, but will support the intention. Currently their are many articles written in different languaged Wikipedia, but are unlinkable=unreachable, which is sad. Wotheina (talk) 12:35, 21 December 2020 (UTC)
  •   Support S8321414 (talk) 14:40, 21 December 2020 (UTC)
  •   Support NicoScribe (talk) 16:54, 21 December 2020 (UTC)

Time and date handling improvements

  • 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)

Discussion

Voting

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

  • 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)

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)
    • 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)
  • +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)
    • 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)
  • 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)

Voting

  •   Support IagoQnsi (talk) 18:40, 8 December 2020 (UTC)
  •   Support Imz (talk) 20:12, 8 December 2020 (UTC)
  •   Support Trang Oul (talk) 20:23, 8 December 2020 (UTC)
  •   Support Berdajeno (talk) 20:50, 8 December 2020 (UTC)
  •   Support Nashona (talk) 21:56, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 22:23, 8 December 2020 (UTC)
  •   Support Nw520 (talk) 22:36, 8 December 2020 (UTC)
  •   Support josecurioso ❯❯❯ Tell me! 22:59, 8 December 2020 (UTC)
  •   Support Frettie (talk) 23:06, 8 December 2020 (UTC)
  •   Support Mahir256 (talk) 01:33, 9 December 2020 (UTC)
  •   Support Hanif Al Husaini (talk) 01:46, 9 December 2020 (UTC)
  •   Support Silver hr (talk) 02:43, 9 December 2020 (UTC)
  •   Support NMaia (talk) 03:07, 9 December 2020 (UTC)
  •   Support Alkari (talk) 03:31, 9 December 2020 (UTC)
  •   Support Tmv (talk) 09:06, 9 December 2020 (UTC)
  •   Support Kpjas (talk) 11:22, 9 December 2020 (UTC)
  •   Support Would better align Wikidata with Library of Congress best practices for archival records, for instance. Currently qualifiers are used but prevalence is uneven. Arlo Barnes (talk) 16:16, 9 December 2020 (UTC)
  •   SupportKwj2772 (msg) 17:11, 9 December 2020 (UTC)
  •   Support Петър Петров (talk) 17:31, 9 December 2020 (UTC)
  •   Support A reasonable and easy fix to a small but widespread problem. {{u|Sdkb}}talk 18:27, 9 December 2020 (UTC)
  •   Supportputnik 19:26, 9 December 2020 (UTC)
  •   Support [Declaring an interest, as a contributor to the EDTF standard] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:37, 9 December 2020 (UTC)
  •   Support Moebeus (talk) 21:54, 9 December 2020 (UTC)
  •   Support Ecritures (talk) 21:55, 9 December 2020 (UTC)
  •   Support Blue Rasberry (talk) 01:44, 10 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:02, 10 December 2020 (UTC)
  •   Support Jim Bey (talk) 13:08, 10 December 2020 (UTC)
  •   Support Libcub (talk) 20:53, 10 December 2020 (UTC)
  •   Support OwenBlacker (Talk) 21:23, 10 December 2020 (UTC)
  •   Support Jc86035 (talk) 12:06, 11 December 2020 (UTC)
  •   Support Paucabot (talk) 12:10, 11 December 2020 (UTC)
  •   Support Dhx1 (talk) 12:38, 11 December 2020 (UTC)
  •   Support Watty62 (talk) 14:34, 11 December 2020 (UTC)
  •   Support Thadguidry (talk) 14:58, 11 December 2020 (UTC)
  •   Support Rhudson (talk) 15:21, 11 December 2020 (UTC)
  •   Support Librarian lena (talk) 15:26, 11 December 2020 (UTC)
  •   Support Lmbarrier (talk) 15:34, 11 December 2020 (UTC)
  •   Support H. Mary (talk) 15:38, 11 December 2020 (UTC)
  •   Support Steganogram (talk) 15:38, 11 December 2020 (UTC)
  •   Support Pajaritowiki (talk) 15:44, 11 December 2020 (UTC)
  •   Support Bethpc (talk) 16:08, 11 December 2020 (UTC)
  •   Support This would be very handy. Right now there's no proper way to indicate something like this except for a decade (which is not very specific). Husky (talk) 16:15, 11 December 2020 (UTC)
  •   Support Kgronsbell (talk) 16:42, 11 December 2020 (UTC)
  •   Support Poslovitch (talk) 16:44, 11 December 2020 (UTC)
  •   Support Susanna Giaccai (talk) 16:51, 11 December 2020 (UTC)
  •   Support Arnd (talk) 17:14, 11 December 2020 (UTC)
  •   Support Clements.UWLib (talk) 17:55, 11 December 2020 (UTC)
  •   Support Saumier (talk) 18:27, 11 December 2020 (UTC)
  •   Support Jimfhahn (talk) 18:41, 11 December 2020 (UTC)
  •   Support Chrisjowaisas (talk) 19:14, 11 December 2020 (UTC)
  •   Support RobbieIanMorrison (talk) 19:19, 11 December 2020 (UTC)
  •   Support Zidmgmt (talk) 19:23, 11 December 2020 (UTC)
  •   Support Crazy1880 (talk) 19:48, 11 December 2020 (UTC)
  •   Support Erussey (talk) 20:16, 11 December 2020 (UTC)
  •   Support Meejies (talk) 00:11, 12 December 2020 (UTC)
  •   Support Redalert2fan (talk) 00:22, 12 December 2020 (UTC)
  •   Support Mauricio V. Genta (talk) 05:54, 12 December 2020 (UTC)
  •   Support Francois-Pier (talk) 09:41, 12 December 2020 (UTC)
  •   Support Strainu (talk) 10:34, 12 December 2020 (UTC)
  •   Support Codl (talk) 14:51, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:28, 12 December 2020 (UTC)
  •   Neutral improving modeling of the dates on Wikidata is an ongoing issue and there are many long standing tickets related to it. However this proposal provides alternative modeling solution to the current practice of modeling more nuanced dates with qualifiers (see d:Help:Dates#Qualifiers), without addressing the issue how are those 2 standards going to coexist. --Jarekt (talk) 15:46, 12 December 2020 (UTC)
  •   Support. Meiræ 21:58, 12 December 2020 (UTC)
  •   Support Would enable widespread interoperability, absolutely! Brimwats (talk) 02:47, 13 December 2020 (UTC)
  •   Support   hugarheimur 08:49, 14 December 2020 (UTC)
  •   Support —— Eric Liu留言百科用戶頁 11:56, 14 December 2020 (UTC)
  •   Support Yarl (talk) 14:30, 14 December 2020 (UTC)
  •   Support TiagoLubiana (talk) 17:37, 15 December 2020 (UTC)
  •   Support Mohanad Kh Talk 06:00, 16 December 2020 (UTC)
  •   Support Pullen255 (talk) 12:53, 17 December 2020 (UTC)
  •   Support GiFontenelle (talk) 01:19, 18 December 2020 (UTC)
  •   Support Jklamo (talk) 16:18, 19 December 2020 (UTC)
  •   Support Mijam23 (talk) 19:12, 20 December 2020 (UTC)
  •   Support Fringilla (talk) 19:52, 20 December 2020 (UTC)
  •   Support S8321414 (talk) 14:40, 21 December 2020 (UTC)
  •   Support --Mbrinkerink (talk) 08:52, 14 May 2021 (UTC)

sort statements as you wish

  • 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)

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)

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)
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)
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)

Voting

  •   Support CrystallineLeMonde (talk) 20:04, 8 December 2020 (UTC)
  •   Support Imz (talk) 20:07, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 22:27, 8 December 2020 (UTC)
  •   Support Wallacegromit1 (talk) 10:43, 9 December 2020 (UTC)
  •   Support DrThneed (talk) 00:45, 10 December 2020 (UTC)
  •   Support Libcub (talk) 20:55, 10 December 2020 (UTC)
  •   Support BugWarp (talk) 13:41, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 18:27, 11 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:27, 12 December 2020 (UTC)
  •   Support Luca.favorido (talk) 19:45, 12 December 2020 (UTC)
  •   Support. Meiræ 22:03, 12 December 2020 (UTC)
  •   Support DGtal (talk) 08:15, 13 December 2020 (UTC)
  •   Support Geagea (talk) 14:19, 13 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 13:57, 15 December 2020 (UTC)
  •   Support TiagoLubiana (talk) 20:15, 15 December 2020 (UTC)
  •   Support Ideally, there'd be options to group claims of similar nature. ShiehJ (talk) 20:51, 15 December 2020 (UTC)
  •   Support Jklamo (talk) 16:20, 19 December 2020 (UTC)

Extend Gadget - Drag'n'drop

  • 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)

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)

Voting

  •   Support Libcub (talk) 21:02, 10 December 2020 (UTC)
  •   Support BoldLuis (talk) 18:26, 11 December 2020 (UTC)
  •   Support Mauricio V. Genta (talk) 05:54, 12 December 2020 (UTC)
  •   Support Tom Ja (talk) 09:53, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:04, 12 December 2020 (UTC)
  •   Support oh, yes, please Kku (talk) 07:30, 17 December 2020 (UTC)

Slow and fast edits

  • Problem: WDQS is overloaded by a number of edits, many of them are unimportant.
  • Who would benefit:
  • Proposed solution: We introduce a new parameter "slow" which will deprioritize change dispatch/WDQS. See d:User_talk:BrokenSegue/API_Proxy#New_"slow"_parameter.
  • More comments:
  • Phabricator tickets:
  • Proposer: GZWDer (talk) 06:20, 26 November 2020 (UTC)

Discussion

Voting

  •   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)
  •   Support Jcwang1986 (talk) 08:56, 9 December 2020 (UTC)
  •   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)
  •   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)
  •   Support Thomas Kinz (talk) 21:34, 9 December 2020 (UTC)
  •   Oppose - This proposal is far too broad and not properly worked out. Husky (talk) 16:16, 11 December 2020 (UTC)
  •   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)
  •   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)
  •   Oppose --Jarekt (talk) 15:20, 12 December 2020 (UTC)
  •   Support Kartsriv (talk) 17:24, 19 December 2020 (UTC)

Duplicates and merge candidates

  • 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)

Discussion

  • Removed the Phabricator task as it's not relevant. --Matěj Suchánek (talk) 15:54, 20 November 2020 (UTC)
  • @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)
    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)
  • 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)
    Or if not same name, perhaps with some other String Metric and comparing properties..--Sabas88 (talk) 12:45, 25 November 2020 (UTC)

Voting

  •   Support Movses (talk) 19:38, 8 December 2020 (UTC)
  •   Support マイキ (talk) 19:39, 8 December 2020 (UTC)
  •   Support Imz (talk) 20:13, 8 December 2020 (UTC)
  •   Support Ferdi2005[Mail] 20:44, 8 December 2020 (UTC)
  •   Support Mcampany (talk) 21:40, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 22:28, 8 December 2020 (UTC)
  •   Support RXerself (talk) 23:53, 8 December 2020 (UTC)
  •   Support BALA. RTalk 01:44, 9 December 2020 (UTC)
  •   Support Tarnumg (talk) 02:12, 9 December 2020 (UTC)
  •   Support NMaia (talk) 03:09, 9 December 2020 (UTC)
  •   Support Chrisaliv (talk) 05:35, 9 December 2020 (UTC)
  •   Support example: many location related duplicates from svwiki amd cebwiki with actual source seemingly being Geonames katpatuka (talk) 06:06, 9 December 2020 (UTC)
  •   Support Omda4wady (talk) 07:32, 9 December 2020 (UTC)
  •   Support Avron (talk) 07:36, 9 December 2020 (UTC)
  •   Support Kpjas (talk) 11:30, 9 December 2020 (UTC)
  •   Support Akela (talk) 12:57, 9 December 2020 (UTC)
  •   Support Delpha (talk) 13:07, 9 December 2020 (UTC)
  •   Support Bietels (talk) 14:13, 9 December 2020 (UTC)
  •   Support Nehaoua (talk) 16:45, 9 December 2020 (UTC)
  •   Support Петър Петров (talk) 17:31, 9 December 2020 (UTC)
  •   Support JAn Dudík (talk) 20:29, 9 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:02, 10 December 2020 (UTC)
  •   Support - yona B. (D) 08:23, 10 December 2020 (UTC)
  •   Support Susanna Ånäs (Susannaanas) (talk) 11:02, 10 December 2020 (UTC)
  •   Support Euro know (talk) 11:26, 10 December 2020 (UTC)
  •   Support Sasuke Sarutobi (talk) 23:34, 10 December 2020 (UTC)
  •   Support Higa4 (talk) 04:58, 11 December 2020 (UTC)
  •   Support Paucabot (talk) 12:12, 11 December 2020 (UTC)
  •   Support Watty62 (talk) 14:44, 11 December 2020 (UTC)
  •   Support Husky (talk) 16:13, 11 December 2020 (UTC)
  •   Support Bencemac (talk) 16:16, 11 December 2020 (UTC)
  •   Support Poslovitch (talk) 16:45, 11 December 2020 (UTC)
  •   Support Susanna Giaccai (talk) 16:50, 11 December 2020 (UTC)
  •   Support Theklan (talk) 18:20, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 18:27, 11 December 2020 (UTC)
  •   Support Francois-Pier (talk) 08:35, 12 December 2020 (UTC)
  •   Support Tom Ja (talk) 09:54, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:00, 12 December 2020 (UTC)
  •   Neutral I support the improvements to the merge tools, but for me the most needed would be creation of Merge tool that allows "Unmerge" option as I see a lot of bad merges done with easy to use merge tools used by users with very little experience. This proposal does not mentions any Unmerge options. --Jarekt (talk) 15:29, 12 December 2020 (UTC)
  •   Support it could be useful, and could encourage the usage of "different from" property on similar elements Luca.favorido (talk) 19:42, 12 December 2020 (UTC)
  •   Support. Meiræ 22:00, 12 December 2020 (UTC)
  •   Support Gelli1742 (talk) 20:21, 13 December 2020 (UTC)
  •   Support C. crispus (talk) 07:46, 14 December 2020 (UTC)
  •   Support --Mosbatho (talk) 21:58, 14 December 2020 (UTC)
  •   Support Nurtenge (talk) 06:59, 15 December 2020 (UTC)
  •   Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:42, 15 December 2020 (UTC)
  •   Support MTheiler (talk) 15:13, 15 December 2020 (UTC)
  •   Support Utopes (talk) 19:26, 15 December 2020 (UTC)
  •   Support TemboUngwe (talk) 15:28, 16 December 2020 (UTC)
  •   Support --Luan (discussão) 19:50, 16 December 2020 (UTC)
  •   Support F. Riedelio (talk) 10:25, 17 December 2020 (UTC)
  •   Support GiFontenelle (talk) 00:41, 18 December 2020 (UTC)
  •   Support Nashona (talk) 01:51, 19 December 2020 (UTC)
  •   Support Patsagorn Y. (Talk) 04:53, 19 December 2020 (UTC)
  •   Support Iva (talk) 16:03, 20 December 2020 (UTC)
  •   Support — Baidax 💬 17:15, 21 December 2020 (UTC)

Expand automatic edit summaries

  • 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)

Discussion

Voting

  •   Support AllyD (talk) 19:40, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 22:24, 8 December 2020 (UTC)
  •   Support Silver hr (talk) 02:26, 9 December 2020 (UTC)
  •   Support; this definitely deserves attention. As an alternative, a javascript-based solution similar to wikidata:User:Yair rand/DiffLists.js on Wikidata itself might be possible to enhance the watchlist experience on client wikis. —MisterSynergy (talk) 09:07, 9 December 2020 (UTC)
  •   Support Kpjas (talk) 11:21, 9 December 2020 (UTC)
  •   Support ‐‐1997kB (talk) 12:49, 9 December 2020 (UTC)
  •   Support Nehaoua (talk) 16:44, 9 December 2020 (UTC)
  •   Support Better watchlisting of Wikidata is a vital step in addressing its vandalism problem. This should be an easy enough fix given it's already what appears on Wikidata itself. {{u|Sdkb}}talk 18:34, 9 December 2020 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 9 December 2020 (UTC)
  •   Support DrThneed (talk) 00:58, 10 December 2020 (UTC)
  •   Support Libcub (talk) 21:09, 10 December 2020 (UTC)
  •   Support OwenBlacker (Talk) 21:25, 10 December 2020 (UTC)
  •   Support Watty62 (talk) 14:39, 11 December 2020 (UTC)
  •   Support Izno (talk) 15:51, 11 December 2020 (UTC)
  •   Support Somej (talk) 21:13, 11 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:12, 12 December 2020 (UTC)
  •   Support Nikkimaria (talk) 16:36, 13 December 2020 (UTC)
  •   Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:45, 15 December 2020 (UTC)
  •   Support Pelagic (talk) 18:40, 15 December 2020 (UTC)
  •   Support Jklamo (talk) 16:24, 19 December 2020 (UTC)
  •   Support 郑洲扬 (talk) 12:34, 20 December 2020 (UTC)
  •   Support Kelvin (talk) 09:43, 21 December 2020 (UTC)
  •   Support Golmore (talk) 17:49, 21 December 2020 (UTC)

Anti-vandalism tools for Wikidata

  • 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)

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)
  • Yes, this is needed so badly. {{u|Sdkb}}talk 02:43, 17 November 2020 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • tools are needed but rather than twinkle / huggle, you need an ORES AI built on existing reversion dataset. the high confidence vandalism can get reverted by bot, with the less confident vandalism sent to a response queue. with human intervention by editor not edit, trying to pivot editors to productive editing. good faith mistaken edits should go to a coaching queue. you would need to train a task force of responders in how to act in a firm but fair way - edit warring over individual edits is a failed model. the tools will not attract the vandal fighters, rather the response team must be recruited to increase data quality. Slowking4 (talk) 02:13, 27 November 2020 (UTC)

Voting