Community Wishlist Survey 2021/Wikidata

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
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)

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)

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 Support Geert Van Pamel (WMBE) (talk) 19:09, 8 December 2020 (UTC)
  • Support Support Imz (talk) 20:10, 8 December 2020 (UTC)
  • Support Support Ssstela (talk) 21:30, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 22:26, 8 December 2020 (UTC)
  • Support Support NMaia (talk) 03:07, 9 December 2020 (UTC)
  • Support 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 Support For all the good reasons mentioned above Paul Hermans 08:19, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:20, 9 December 2020 (UTC)
  • Support Support DaSupremo (talk) 16:37, 9 December 2020 (UTC)
  • Support Support Lirazelf (talk) 17:15, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 01:57, 10 December 2020 (UTC)
  • Support Support Watty62 (talk) 14:46, 11 December 2020 (UTC)
  • Support Support Susanna Giaccai (talk) 16:48, 11 December 2020 (UTC)
  • Support Support not only bibliographical, but useful for webSources as well  Klaas `Z4␟` V:  15:39, 12 December 2020 (UTC)
  • Support Support. Meiræ 21:56, 12 December 2020 (UTC)
  • Support Support ViktorQT (talk) 13:55, 14 December 2020 (UTC)
  • Support Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:46, 15 December 2020 (UTC)
  • Support Support Kku (talk) 07:25, 17 December 2020 (UTC)
  • Support Support AdaHephais (talk) 05:42, 20 December 2020 (UTC)
  • Support Support S8321414 (talk) 14:40, 21 December 2020 (UTC)

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)

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

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)

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 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 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 Support This would bring Wikidata inline with how Wikipedia thinks of redirects. IagoQnsi (talk) 18:38, 8 December 2020 (UTC)
  • Support Support Imz (talk) 20:06, 8 December 2020 (UTC)
  • Support Support Berdajeno (talk) 20:37, 8 December 2020 (UTC)
  • Support Support Tcit (talk) 21:29, 8 December 2020 (UTC)
  • Support Support Pi.1415926535 (talk) 21:29, 8 December 2020 (UTC)
  • Support Support Epìdosis 21:35, 8 December 2020 (UTC)
  • Support Support Nw520 (talk) 22:51, 8 December 2020 (UTC)
  • Support Support I hope it would be useful for my problems RXerself (talk) 00:09, 9 December 2020 (UTC)
  • Support Support 5225C (talkcontributions) 00:19, 9 December 2020 (UTC)
  • Support Support--Alexmar983 (talk) 01:19, 9 December 2020 (UTC)
  • Support Support Kaldari (talk) 02:55, 9 December 2020 (UTC)
  • Support Support Shyamal (talk) 03:37, 9 December 2020 (UTC)
  • Support Support {{u|Sdkb}}talk 04:09, 9 December 2020 (UTC)
  • Support 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 Support Obvious support, there is no downside to this that I can see MSGJ (talk) 08:41, 9 December 2020 (UTC)
  • Support 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 Support Kpjas (talk) 11:23, 9 December 2020 (UTC)
  • Support Support ArthurPSmith (talk) 15:56, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 16:40, 9 December 2020 (UTC)
  • Support Support. Simon Cobb (Sic19 ; talk page) 18:04, 9 December 2020 (UTC)
  • Support Supportputnik 19:28, 9 December 2020 (UTC)
  • Support Support JAn Dudík (talk) 20:30, 9 December 2020 (UTC)
  • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 9 December 2020 (UTC)
  • Support Support Mike Peel (talk) 20:45, 9 December 2020 (UTC)
  • Support Support Ecritures (talk) 21:58, 9 December 2020 (UTC)
  • Support Support Moebeus (talk) 22:05, 9 December 2020 (UTC)
  • Support Support crazy idea, makes sense Blue Rasberry (talk) 01:42, 10 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 01:56, 10 December 2020 (UTC)
  • Support Support Efly (talk) 10:40, 10 December 2020 (UTC)
  • Support Support - Valentina.Anitnelav (talk) 12:06, 10 December 2020 (UTC)
  • Support Support Dexxor (talk) 16:44, 10 December 2020 (UTC)
  • Support Support Evad37 (talk) 09:08, 11 December 2020 (UTC)
  • Support Support Dhx1 (talk) 12:54, 11 December 2020 (UTC)
  • Support Support Watty62 (talk) 14:47, 11 December 2020 (UTC)
  • Support Support Jc86035 (talk) 16:24, 11 December 2020 (UTC)
  • Support Support Susanna Giaccai (talk) 16:53, 11 December 2020 (UTC)
  • Support Support BoldLuis (talk) 18:29, 11 December 2020 (UTC)
  • Support Support --Kusurija (talk) 18:44, 11 December 2020 (UTC)
  • Support Support Stevenliuyi (talk) 22:14, 11 December 2020 (UTC)
  • Support Support Loopy30 (talk) 23:32, 11 December 2020 (UTC)
  • Support Support --Alaa :)..! 01:27, 12 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  15:25, 12 December 2020 (UTC)
  • Support Support. Meiræ 22:02, 12 December 2020 (UTC)
  • Support Support NoInkling (talk) 01:17, 13 December 2020 (UTC)
  • Support Support Shushugah (talk) 21:42, 13 December 2020 (UTC)
  • Support Support Yes please. This would solve a quite annoying problem which has made Wikidata essentially unsuitable for managing interwiki links. TRN 3.svg hugarheimur 08:53, 14 December 2020 (UTC)
  • Support Support Michel Bakni (talk) 14:01, 14 December 2020 (UTC)
  • Support Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:44, 15 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:57, 15 December 2020 (UTC)
  • Support Support SeGiba (talk) 18:05, 15 December 2020 (UTC)
  • Support Support. Make interlanguage links great again. Pelagic (talk) 18:24, 15 December 2020 (UTC)
  • Support 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 Support Tilon3 (talk) 06:42, 16 December 2020 (UTC)
  • Support Support Katzmann83 (talk) 14:25, 16 December 2020 (UTC)
  • Support Support --Luan (discussão) 19:50, 16 December 2020 (UTC)
  • Support 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 Support Gdafs (talk) 15:05, 17 December 2020 (UTC)
  • Support Support Waiting for this since years Ameisenigel (talk) 15:43, 17 December 2020 (UTC)
  • Support Support Jklamo (talk) 16:21, 19 December 2020 (UTC)
  • Support Support AdaHephais (talk) 05:46, 20 December 2020 (UTC)
  • Support Support Fringilla (talk) 19:55, 20 December 2020 (UTC)
  • Support 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 Support S8321414 (talk) 14:40, 21 December 2020 (UTC)
  • Support Support NicoScribe (talk) 16:54, 21 December 2020 (UTC)

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)

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)

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)

Voting

  • Support Support IagoQnsi (talk) 18:40, 8 December 2020 (UTC)
  • Support Support Imz (talk) 20:12, 8 December 2020 (UTC)
  • Support Support Trang Oul (talk) 20:23, 8 December 2020 (UTC)
  • Support Support Berdajeno (talk) 20:50, 8 December 2020 (UTC)
  • Support Support Nashona (talk) 21:56, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 22:23, 8 December 2020 (UTC)
  • Support Support Nw520 (talk) 22:36, 8 December 2020 (UTC)
  • Support Support josecurioso ❯❯❯ Tell me! 22:59, 8 December 2020 (UTC)
  • Support Support Frettie (talk) 23:06, 8 December 2020 (UTC)
  • Support Support Mahir256 (talk) 01:33, 9 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 01:46, 9 December 2020 (UTC)
  • Support Support Silver hr (talk) 02:43, 9 December 2020 (UTC)
  • Support Support NMaia (talk) 03:07, 9 December 2020 (UTC)
  • Support Support Alkari (talk) 03:31, 9 December 2020 (UTC)
  • Support Support Tmv (talk) 09:06, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:22, 9 December 2020 (UTC)
  • Support 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)
  • Support SupportKwj2772 (msg) 17:11, 9 December 2020 (UTC)
  • Support Support Петър Петров (talk) 17:31, 9 December 2020 (UTC)
  • Support Support A reasonable and easy fix to a small but widespread problem. {{u|Sdkb}}talk 18:27, 9 December 2020 (UTC)
  • Support Supportputnik 19:26, 9 December 2020 (UTC)
  • Support 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 Support Moebeus (talk) 21:54, 9 December 2020 (UTC)
  • Support Support Ecritures (talk) 21:55, 9 December 2020 (UTC)
  • Support Support Blue Rasberry (talk) 01:44, 10 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 02:02, 10 December 2020 (UTC)
  • Support Support Jim Bey (talk) 13:08, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 20:53, 10 December 2020 (UTC)
  • Support Support OwenBlacker (Talk) 21:23, 10 December 2020 (UTC)
  • Support Support Jc86035 (talk) 12:06, 11 December 2020 (UTC)
  • Support Support Paucabot (talk) 12:10, 11 December 2020 (UTC)
  • Support Support Dhx1 (talk) 12:38, 11 December 2020 (UTC)
  • Support Support Watty62 (talk) 14:34, 11 December 2020 (UTC)
  • Support Support Thadguidry (talk) 14:58, 11 December 2020 (UTC)
  • Support Support Rhudson (talk) 15:21, 11 December 2020 (UTC)
  • Support Support Librarian lena (talk) 15:26, 11 December 2020 (UTC)
  • Support Support Lmbarrier (talk) 15:34, 11 December 2020 (UTC)
  • Support Support H. Mary (talk) 15:38, 11 December 2020 (UTC)
  • Support Support Steganogram (talk) 15:38, 11 December 2020 (UTC)
  • Support Support Pajaritowiki (talk) 15:44, 11 December 2020 (UTC)
  • Support Support Bethpc (talk) 16:08, 11 December 2020 (UTC)
  • Support 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 Support Kgronsbell (talk) 16:42, 11 December 2020 (UTC)
  • Support Support Poslovitch (talk) 16:44, 11 December 2020 (UTC)
  • Support Support Susanna Giaccai (talk) 16:51, 11 December 2020 (UTC)
  • Support Support Arnd (talk) 17:14, 11 December 2020 (UTC)
  • Support Support Clements.UWLib (talk) 17:55, 11 December 2020 (UTC)
  • Support Support Saumier (talk) 18:27, 11 December 2020 (UTC)
  • Support Support Jimfhahn (talk) 18:41, 11 December 2020 (UTC)
  • Support Support Chrisjowaisas (talk) 19:14, 11 December 2020 (UTC)
  • Support Support RobbieIanMorrison (talk) 19:19, 11 December 2020 (UTC)
  • Support Support Zidmgmt (talk) 19:23, 11 December 2020 (UTC)
  • Support Support Crazy1880 (talk) 19:48, 11 December 2020 (UTC)
  • Support Support Erussey (talk) 20:16, 11 December 2020 (UTC)
  • Support Support Meejies (talk) 00:11, 12 December 2020 (UTC)
  • Support Support Redalert2fan (talk) 00:22, 12 December 2020 (UTC)
  • Support Support Mauricio V. Genta (talk) 05:54, 12 December 2020 (UTC)
  • Support Support Francois-Pier (talk) 09:41, 12 December 2020 (UTC)
  • Support Support Strainu (talk) 10:34, 12 December 2020 (UTC)
  • Support Support Codl (talk) 14:51, 12 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  15:28, 12 December 2020 (UTC)
  • Neutral 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 Support. Meiræ 21:58, 12 December 2020 (UTC)
  • Support Support Would enable widespread interoperability, absolutely! Brimwats (talk) 02:47, 13 December 2020 (UTC)
  • Support Support TRN 3.svg hugarheimur 08:49, 14 December 2020 (UTC)
  • Support Support —— Eric Liu留言百科用戶頁 11:56, 14 December 2020 (UTC)
  • Support Support Yarl (talk) 14:30, 14 December 2020 (UTC)
  • Support Support TiagoLubiana (talk) 17:37, 15 December 2020 (UTC)
  • Support Support Mohanad Kh Talk 06:00, 16 December 2020 (UTC)
  • Support Support Pullen255 (talk) 12:53, 17 December 2020 (UTC)
  • Support Support GiFontenelle (talk) 01:19, 18 December 2020 (UTC)
  • Support Support Jklamo (talk) 16:18, 19 December 2020 (UTC)
  • Support Support Mijam23 (talk) 19:12, 20 December 2020 (UTC)
  • Support Support Fringilla (talk) 19:52, 20 December 2020 (UTC)
  • Support Support S8321414 (talk) 14:40, 21 December 2020 (UTC)

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)

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

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)

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

Slow and fast edits

Edit proposal/discussion

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

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)

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 Support Movses (talk) 19:38, 8 December 2020 (UTC)
  • Support Support マイキ (talk) 19:39, 8 December 2020 (UTC)
  • Support Support Imz (talk) 20:13, 8 December 2020 (UTC)
  • Support Support Ferdi2005[Mail] 20:44, 8 December 2020 (UTC)
  • Support Support Mcampany (talk) 21:40, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 22:28, 8 December 2020 (UTC)
  • Support Support RXerself (talk) 23:53, 8 December 2020 (UTC)
  • Support Support BALA. RTalk 01:44, 9 December 2020 (UTC)
  • Support Support Tarnumg (talk) 02:12, 9 December 2020 (UTC)
  • Support Support NMaia (talk) 03:09, 9 December 2020 (UTC)
  • Support Support Chrisaliv (talk) 05:35, 9 December 2020 (UTC)
  • Support 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 Support Omda4wady (talk) 07:32, 9 December 2020 (UTC)
  • Support Support Avron (talk) 07:36, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:30, 9 December 2020 (UTC)
  • Support Support Akela (talk) 12:57, 9 December 2020 (UTC)
  • Support Support Delpha (talk) 13:07, 9 December 2020 (UTC)
  • Support Support Bietels (talk) 14:13, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 16:45, 9 December 2020 (UTC)
  • Support Support Петър Петров (talk) 17:31, 9 December 2020 (UTC)
  • Support Support JAn Dudík (talk) 20:29, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 02:02, 10 December 2020 (UTC)
  • Support Support - yona B. (D) 08:23, 10 December 2020 (UTC)
  • Support Support Susanna Ånäs (Susannaanas) (talk) 11:02, 10 December 2020 (UTC)
  • Support Support Euro know (talk) 11:26, 10 December 2020 (UTC)
  • Support Support Sasuke Sarutobi (talk) 23:34, 10 December 2020 (UTC)
  • Support Support Higa4 (talk) 04:58, 11 December 2020 (UTC)
  • Support Support Paucabot (talk) 12:12, 11 December 2020 (UTC)
  • Support Support Watty62 (talk) 14:44, 11 December 2020 (UTC)
  • Support Support Husky (talk) 16:13, 11 December 2020 (UTC)
  • Support Support Bencemac (talk) 16:16, 11 December 2020 (UTC)
  • Support Support Poslovitch (talk) 16:45, 11 December 2020 (UTC)
  • Support Support Susanna Giaccai (talk) 16:50, 11 December 2020 (UTC)
  • Support Support Theklan (talk) 18:20, 11 December 2020 (UTC)
  • Support Support BoldLuis (talk) 18:27, 11 December 2020 (UTC)
  • Support Support Francois-Pier (talk) 08:35, 12 December 2020 (UTC)
  • Support Support Tom Ja (talk) 09:54, 12 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  15:00, 12 December 2020 (UTC)
  • Neutral 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 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 Support. Meiræ 22:00, 12 December 2020 (UTC)
  • Support Support Gelli1742 (talk) 20:21, 13 December 2020 (UTC)
  • Support Support C. crispus (talk) 07:46, 14 December 2020 (UTC)
  • Support Support --Mosbatho (talk) 21:58, 14 December 2020 (UTC)
  • Support Support Nurtenge (talk) 06:59, 15 December 2020 (UTC)
  • Support Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:42, 15 December 2020 (UTC)
  • Support Support MTheiler (talk) 15:13, 15 December 2020 (UTC)
  • Support Support Utopes (talk) 19:26, 15 December 2020 (UTC)
  • Support Support TemboUngwe (talk) 15:28, 16 December 2020 (UTC)
  • Support Support --Luan (discussão) 19:50, 16 December 2020 (UTC)
  • Support Support F. Riedelio (talk) 10:25, 17 December 2020 (UTC)
  • Support Support GiFontenelle (talk) 00:41, 18 December 2020 (UTC)
  • Support Support Nashona (talk) 01:51, 19 December 2020 (UTC)
  • Support Support Patsagorn Y. (Talk) 04:53, 19 December 2020 (UTC)
  • Support Support Iva (talk) 16:03, 20 December 2020 (UTC)
  • Support Support — Baidax 💬 17:15, 21 December 2020 (UTC)

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)

Discussion

Voting

  • Support Support AllyD (talk) 19:40, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 22:24, 8 December 2020 (UTC)
  • Support Support Silver hr (talk) 02:26, 9 December 2020 (UTC)
  • Support 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 Support Kpjas (talk) 11:21, 9 December 2020 (UTC)
  • Support Support ‐‐1997kB (talk) 12:49, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 16:44, 9 December 2020 (UTC)
  • Support 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 Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 9 December 2020 (UTC)
  • Support Support DrThneed (talk) 00:58, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 21:09, 10 December 2020 (UTC)
  • Support Support OwenBlacker (Talk) 21:25, 10 December 2020 (UTC)
  • Support Support Watty62 (talk) 14:39, 11 December 2020 (UTC)
  • Support Support Izno (talk) 15:51, 11 December 2020 (UTC)
  • Support Support Somej (talk) 21:13, 11 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  15:12, 12 December 2020 (UTC)
  • Support Support Nikkimaria (talk) 16:36, 13 December 2020 (UTC)
  • Support Support  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:45, 15 December 2020 (UTC)
  • Support Support Pelagic (talk) 18:40, 15 December 2020 (UTC)
  • Support Support Jklamo (talk) 16:24, 19 December 2020 (UTC)
  • Support Support 郑洲扬 (talk) 12:34, 20 December 2020 (UTC)
  • Support Support Kelvin (talk) 09:43, 21 December 2020 (UTC)
  • Support Support Golmore (talk) 17:49, 21 December 2020 (UTC)

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)

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

Access to Wikidata from external (Media)Wikis

Edit proposal/discussion

  • Problem: Wikidata should be accessible from non-wm wikis as well.
Deutsch: Es sollte ein Zugriff auf die Daten von Wikidata auch aus fremden Wikis möglich sein.
  • Who would benefit: MediaWikis hosted outside of WMF*infrastructure could use data from Wikidata in an easy way, which could otherwise foster to contribute to this project.
Deutsch: Viele Wikis in allen Sprachen außerhalb der Wikimediawelt hätten die Möglichkeit auf permanent aktuelle Daten.
  • Proposed solution: I think there is a need for a MediaWiki-extension which could easily {{#invoke}} data from Wikidata also in an wmf-external mediawiki. especially if an external wiki is already linked with Wikidata by an external-id property (e.g. P6228 or P8713) there should be a technical possibility to configurate the external wiki on which way the local wiki is linked to Wikidata. Let's say - use pageid (as used in P6228) or pageTitle (P8713) and a specific Property to look up for the corresponding Wikidata Item. This should happen in the background so an {{#invoke}} module for external mediawikis could parse the specific values from all the given statements and the linked item.
  • More comments:
Deutsch: Bidirektionale Schnittstellenfunktion zum Abbau von redundanten Informationen und Daten von und zu Wikipedia-Softwarelösungen und Regionalwikis--Kasa Fue (talk) 17:42, 25 November 2020 (UTC)

Discussion

  • Open Citizen Science with regiowikis and wikidata depends highly on open data and their linkages! --Jeb (talk) 14:55, 27 November 2020 (UTC)
  • The advantages using InstantCommons for the integration of external media could also bring advantages for using InstantWikidata data. --Erfurth (talk)

Voting

  • Support Support マイキ (talk) 19:34, 8 December 2020 (UTC)
  • Support Support Erfurth (talk) 20:28, 8 December 2020 (UTC)
  • Support Support Yes great idea. Make an Wikidata extension that is as easy to use as InstantCommons. Flounder ceo (talk) 21:23, 8 December 2020 (UTC)
  • Support Support Agruwie (talk) 21:43, 8 December 2020 (UTC)
  • Support Support Mfchris84 (talk) 00:27, 9 December 2020 (UTC)
  • Support Support Watty62 (talk) 14:32, 11 December 2020 (UTC)
  • Support Support I think that this has overlap with the aim of the LinkedWiki extension. However, LinkedWiki requires expertise and access to the wiki's config files to set-up. AshHinch (talk) 14:57, 11 December 2020 (UTC)
  • Support Support --Mathieugp (talk) 18:29, 11 December 2020 (UTC)
  • Oppose Oppose Happytravels (talk) 19:19, 11 December 2020 (UTC)
  • Support Support --M2k~dewiki (talk) 21:06, 11 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  12:48, 12 December 2020 (UTC)
  • Support Support Braveheart (talk) 15:56, 12 December 2020 (UTC)
  • Support Support --Funke (talk) 19:54, 12 December 2020 (UTC)
  • Support Support Plani (talk) 19:55, 12 December 2020 (UTC)
  • Support Support --AleXXw (talk) 19:56, 12 December 2020 (UTC)
  • Support Support -- Regiomontanus (talk) 19:59, 12 December 2020 (UTC)
  • Support Support Stevenliuyi (talk) 07:16, 13 December 2020 (UTC)
  • Support Support --Geolina163 (talk) 11:53, 13 December 2020 (UTC)
  • Support Support Conny (talk) 14:06, 13 December 2020 (UTC)
  • Support Support Xosé (talk) 18:40, 13 December 2020 (UTC)
  • Support Support Daniel Mietchen (talk) 22:47, 14 December 2020 (UTC)
  • Support Support, but read-only. Non-WMF projects, not subject to our ToU and upcoming UCC should not be able to mass-push data into WikiData.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:40, 15 December 2020 (UTC)
  • Support Support read-only. Daniel Baránek (talk) 22:54, 15 December 2020 (UTC)
  • Support Support Trang Oul (talk) 11:47, 16 December 2020 (UTC)
  • Support Support GiFontenelle (talk) 01:21, 18 December 2020 (UTC)
  • Support Support EncycloABC (talk) 18:34, 18 December 2020 (UTC)
  • Support Support Jklamo (talk) 15:54, 19 December 2020 (UTC)
  • Support Support AdaHephais (talk) 05:43, 20 December 2020 (UTC)

Allow access to some inverse statements through Lua and parser functions

Edit proposal/discussion

  • Problem: Wikidata currently has more than 100 inverse properties, which are in some ways redundant: in theory, if two statements are exact inverses of each other, one should be unnecessary. It is possible to use WDQS (and user scripts, etc.) to find inverses of statements (those matching a given value and property), but this can't be done normally on Wikimedia wikis, which means that a lot of data is effectively impossible to use on wikis. Furthermore, property proposals are occasionally declined because the properties would be unnecessary for querying, even though they would be useful for infoboxes and other templates. Allowing inverses to be accessed would significantly reduce the complexity of using data from certain properties, and would reduce the maintenance burden for properties which currently have inverses.
  • Who would benefit: Template designers, Wikidata editors, Wikimedia readers (particularly on smaller wikis)
  • Proposed solution: Creation of a parser function, Lua function and/or similar in Wikibase to allow inverse statements to be accessed (with a hard limit on how many entities can be returned from one query), automatic display of inverses on Wikidata item pages and other entity pages (also with a hard limit), and some way of integrating the data that is currently stored using inverse label item (P7087). Alternatively, another approach to allowing the data to be surfaced could be taken if that would be more technically feasible.
  • More comments: See also Community Wishlist Survey 2019/Wikidata/Automatically add inverse properties, which targeted the same problem but suffered from the proposed solution's lack of clarity. It was within the top 10 until an objection was raised on technical grounds. Some databases, such as MusicBrainz, already display their "inverses" automatically, so it may be possible to use the approaches of such databases as inspiration or as a basis.
  • Phabricator tickets: phab:T209559
  • Proposer: Jc86035 (talk) 18:46, 20 November 2020 (UTC)

Discussion

  • Instead of enforcing data integrity by maintaining bidirectional relations and navigation along them by the software, this is left to the editors. As a help provided by the software, endless lists of constraint violations and popup messages are created. Enough said? I more and more get the impression that Wikidata is not at all focused on manual editing. Strong support for any solution on bidirectional relations. --Herzi Pinki (talk) 19:32, 20 November 2020 (UTC)
  • This would be very helpful. It will both help making infoboxes with content with Wikidata, remove a reason to have redundant data on Wikidata, and help to get more consistent data. For some properties the same statements would be also be displayed and be editable on the items pages for both the subject and object. --Dipsacus fullonum (talk) 14:00, 21 November 2020 (UTC)
  • This would be good, but I am worried that these would probably be 'expensive' queries. Some sort of caching is probably needed. On the other hand, the inverse properties can be bot-maintained on Wikidata, and we could get a lot stricter with insisting that the inverse property always exists (e.g., with bots enforcing the inverse properties, or removing values that are missing the inverse, on a daily basis). Thanks. Mike Peel (talk) 20:23, 28 November 2020 (UTC)
    @Mike Peel: I think the latter would be the most tenable alternative, although it would obviously be more difficult to maintain, and I think it would be outside the scope of the wishlist survey. I don't think it would make sense to pursue it unless a more permanent solution that involves changes to Wikibase is definitively ruled out. Jc86035 (talk) 10:31, 29 November 2020 (UTC)
    Sorry, no, bot-maintained inverses are a BAD idea. A vandal adds a bad statement. Bot adds inverse. Vandal's statement is reverted. Bot re-adds the original as it's the inverse of the previously bot-added inverse. And other variations on the same problem. I know you're doing some of these already, but it should not be expanded unless all these complexities are clearly addressed. ArthurPSmith (talk) 15:02, 30 November 2020 (UTC)
    @ArthurPSmith: In those cases the editor needs to remove both of the inverse properties, not just one of them. It's a little bit more work but it's not that much. However, I'm all for a better solution here! Thanks. Mike Peel (talk) 16:50, 30 November 2020 (UTC)
    @Mike Peel: Realistically, would the queries being expensive actually be a significant problem for the parser functions? MediaWiki already has several expensive parser functions, which the proposed parser functions seem roughly comparable to, and it seems unlikely to me that a single infobox would ever need to have 100 "expensive" queries for inverse statements. Given w:WP:PERF and MediaWiki's already-aggressive page caching, I would hope that this wouldn't be a problem inherent to the proposal. Jc86035 (talk) 17:18, 30 November 2020 (UTC)
    I'm more worried about the CPU time it would take rather than whether it is classified as 'expensive' in mediawiki terms. The infoboxes on Commons already occasionally run into the 10s limit, and I know de.wikivoyage has similar issues. Thanks. Mike Peel (talk) 17:30, 30 November 2020 (UTC)
  • Yes, yes, yes. Completely agree with Jc86035 and Dipsacus fullonum. Lack of this feature is limiting the ability of Wikidata to change the world.--Vojtěch Dostál (talk) 20:24, 28 November 2020 (UTC)

Voting

  • Support Support Yair rand (talk) 22:24, 8 December 2020 (UTC)
  • Support Support Inverse properties are a huge PITA and in most cases outdated since understandably nobody wants to take care of information which pretty much already exists. Nw520 (talk) 22:59, 8 December 2020 (UTC)
  • Support Support Sabas88 (talk) 23:01, 8 December 2020 (UTC)
  • Support Support BALA. RTalk 01:43, 9 December 2020 (UTC)
  • Support Support Silver hr (talk) 02:09, 9 December 2020 (UTC)
  • Support Support * Pppery * it has begun 02:12, 9 December 2020 (UTC)
  • Support Support NMaia (talk) 03:05, 9 December 2020 (UTC)
  • Support Support Nattayut.L (talk) 03:46, 9 December 2020 (UTC)
  • Support Support This would seem to be an incredibly useful function for both machine learning and reducing the number of categories. Ottawajin (talk) 05:20, 9 December 2020 (UTC)
  • Support Support MisterSynergy (talk) 09:20, 9 December 2020 (UTC)
  • Support Support Important to allow this. ArthurPSmith (talk) 16:02, 9 December 2020 (UTC)
  • Support Support Sannita - not just another it.wiki sysop 16:03, 9 December 2020 (UTC)
  • Support Support I need this!!! Germartin1 (talk) 16:08, 9 December 2020 (UTC)
  • Support Support {{u|Sdkb}}talk 18:31, 9 December 2020 (UTC)
  • Support Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:45, 9 December 2020 (UTC)
  • Support Support Mike Peel (talk) 20:46, 9 December 2020 (UTC)
  • Support Support Moebeus (talk) 21:57, 9 December 2020 (UTC)
  • Support Support Dhx1 (talk) 12:46, 11 December 2020 (UTC)
  • Support Support Watty62 (talk) 14:40, 11 December 2020 (UTC)
  • Support Support Izno (talk) 15:49, 11 December 2020 (UTC)
  • Support Support Fixer88 (talk) 23:08, 11 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  15:36, 12 December 2020 (UTC)
  • Support Support --Dipsacus fullonum (talk) 02:42, 15 December 2020 (UTC)
  • Support Support --Luan (discussão) 19:50, 16 December 2020 (UTC)
  • Support Support Arvelius (talk) 22:47, 16 December 2020 (UTC)
  • Support Support Nashona (talk) 01:42, 19 December 2020 (UTC)
  • Support Support Jklamo (talk) 15:48, 19 December 2020 (UTC)
  • Support Support AdaHephais (talk) 05:39, 20 December 2020 (UTC)
  • Support Support - Nikki (talk) 15:22, 21 December 2020 (UTC)

Link red links to Wikidata, for future reference and more benefits

Edit proposal/discussion

  • Problem: red links can not be linked to Wikidata, although in most cases a decent Wikidata-item already exists
  • Who would benefit: Future writer of the article, plus the reader that hits the red link can already get some info from both WikiData or other languages
  • Proposed solution: Find a format like [[:d:Q8493024:red link|Show this text]] to connect the items
  • More comments:
  • Phabricator tickets:
  • Proposer: Edoderoo (talk) 19:26, 20 November 2020 (UTC)

Discussion

  • I see the point in this proposal but a reader of say a Wikipedia shouldn't come to Wikidata by following a normal looking link without warning, so the link should somehow be marked as a Wikidata link. Also there must be a way to convert the links to Wikidata to ordinary links once a local article on the link topic is created. That can maybe be a bot job. --Dipsacus fullonum (talk) 13:37, 21 November 2020 (UTC)
    • Sure, probably by having the links in a certain different colour, different from the blue links we already have. Edoderoo (talk) 17:57, 21 November 2020 (UTC)
  • @Edoderoo: I don't think the proposal is clear enough. w:Template:Interlanguage link already exists (and is available on multiple wikis), and its functionality seems to overlap substantially with what you've described. Are you proposing functionality that that template already has, or are you proposing that similar functionality should be implemented in MediaWiki or in an extension? Jc86035 (talk) 17:26, 21 November 2020 (UTC)
This template is a en-wiki-thing. I want to link red links on any language, without editing on en-wiki. There is really no overlap at all. Edoderoo (talk) 17:57, 21 November 2020 (UTC)
The template is on the en-wiki and not wikidata. I also thought about something that finds red links in wikidata and deletes it (or maybe writes all the red links on a special page and users can do it Manually themselves). I'll support any solution to this problem. Euro know (talk) 12:26, 22 November 2020 (UTC)
  • I very much like this idea, and I made a mockup of how it could work. – Susanna Ånäs (Susannaanas) (talk) 18:01, 22 November 2020 (UTC)
  • The idea as shown by the mockup by Susanna Ånäs (Susannaanas) is very good and it also allows a red link to remain a red link. Susannaanas seems to support that whatever happens, happens on clicking the red link. I propose that hovering on the red link should do whatever Susannaanas describes. We can even go a step further and when you actually press on the red link, to go to editing (as usual) a new article, prefilled with all available information from wikidata (in the local language), adjusted to existing and expected content. This will allow not only showing the information available (by hovering), but also easier article creation with some content. --FocalPoint (talk) 05:52, 24 November 2020 (UTC)
  • This is already possible with en:Template:Interlanguage link (often used name ill). See the subsection Link to Reasonator and Wikidata. SportsOlympic (talk) 12:11, 24 November 2020 (UTC)
    • The template is not structured, i.e. There are no way to systematically query such information and it can not be ensured to be consistent among pages. Ideally user can use red link sample which will points to a page to allow user to either write article or see articles in other languages (i.e. a MediaWiki:Noarticletext with interwiki link present).--GZWDer (talk) 06:09, 26 November 2020 (UTC)
    • Also, the template has to be created first, and I think we need a solution that is actionable on all existing red links. – Susanna Ånäs (Susannaanas) (talk) 16:12, 26 November 2020 (UTC)
  • I'll support such a thing. My talk at Wikimania 2019 was about essentially the same idea: wikimania:2019:Technology outreach & innovation/Let's completely change how wiki links work. Some people in this discussion mention templates as a solution, but this is not good enough, because templates are different in every wiki. This must be done uniformly in all wikis, so it must be on the common wiki syntax level and not on the template level (another option is to fully implement Global templates, which is necessary anyway, but that project is probably not for Community tech). --Amir E. Aharoni (talk) 08:16, 27 November 2020 (UTC)
  • I proposed something like this already here: Community_Wishlist_Survey_2015/Wikidata, but I misread your problem, which is to keep the color of the link red, which I agree is key in both the discovery process (inline search) as well as the article creation process (doesn't exist? maybe I will make it!). My proposal, like yours, 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). My idea would initiate a dialog box for the one clicking on the redirect. Your proposal to create redirects like this for redlinks is new and could be a different way to tackle the perennial issue of explaining the Bonnie & Clyde problem to newbies. Jane023 (talk) 11:26, 29 November 2020 (UTC)
  • Shouldn't them link to Abstract Wikipedia? The developers should work on Abstract Wikipedia first, and this issue could be resolved once Abstract Wikipedia is opened.--Midleading (talk) 03:55, 1 December 2020 (UTC)
    • This feature should exists independent of Article Placeholder or Abstract Wikipedia.--GZWDer (talk) 05:13, 1 December 2020 (UTC)
  • If the link would work find automatically the correct target page then it would be useful for non-wikipedia wikis (like wikinews, wikivoyage, commons) for automatically linking to wikipedia if target page cannot be found in local wiki. Biggest improvement in this case would be the user interface for selecting the correct target page from external wiki (wikidata). --Zache (talk) 09:32, 1 December 2020 (UTC)
    • Sometimes introduce an placeholder page may achieve better user experience. Note in many Wikipedias links should not directly go to foreign Wikipedia; instead they use a red link with alternative links to other Wikipedia.--GZWDer (talk) 10:41, 1 December 2020 (UTC)
      • I didn't mean really this for Wikipedia, but in example it is common to link from Wikinews, Wikibooks or Wikivoyage to same language Wikipedia. Currently this takes too much manual work as you need first find the page from wikipedia, write the link with explicit target ([[:w:Turku|Turku]] vs [[Turku]]) and then manually test if the link actually works as it is not red if the target page is missing. --Zache (talk) 10:58, 1 December 2020 (UTC)
  • Concern: What happens when someone connects Kenneth B. Smith to a Wikidata item, and then someone creates w:Kenneth Baxter Smith? Especially if we start linking redirects to Wikidata, this could get messy, and I'd want to see some response about how to avoid creating duplicates before I'd be comfortable supporting this. {{u|Sdkb}}talk 18:22, 9 December 2020 (UTC)
  • en:Template:Interlanguage link already does this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:50, 9 December 2020 (UTC)
  • Click on any redlink in russian version of Template:Vulpecula. We are preloading simple boilerplate text that is intended to assist further article creation. Once test is saved, bot will link it to the designated wikidata item. This way redlink behavior is familiar for existing users and we are utilizing some wikidata information Ghuron (talk) 03:52, 10 December 2020 (UTC)
  • I think that the titles of not yet created articles should be stored in a special property of Wikidata. For example, we need to generate links to Q28665219 which will have text Svetlana Mironova (biathlete) because other en:Svetlana Mironova exists. For projects where any data is loaded into infoboxes, the problem of correct automated red wikification is already there. Сидик из ПТУ (talk) 10:49, 10 December 2020 (UTC)

Voting

  • Support Support I do support this and its related Phabricator ticket task T212211 Sannita - not just another it.wiki sysop 20:35, 8 December 2020 (UTC)
  • Support Support Berdajeno (talk) 20:52, 8 December 2020 (UTC)
  • Support Support This will add so much quality to red links, for me it's a no brainer Edoderoo (talk) 20:54, 8 December 2020 (UTC)
  • Support Support Stryn (talk) 21:14, 8 December 2020 (UTC)
  • Support Support Epìdosis 21:36, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 22:24, 8 December 2020 (UTC)
  • Support Support --Zache (talk) 22:50, 8 December 2020 (UTC)
  • Support Support Sabas88 (talk) 22:58, 8 December 2020 (UTC)
  • Support Support since years...--Alexmar983 (talk) 01:20, 9 December 2020 (UTC)
  • Support Support Wallacegromit1 (talk) 10:50, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:27, 9 December 2020 (UTC)
  • Support Support ‐‐1997kB (talk) 12:45, 9 December 2020 (UTC)
  • Support Support Sgd. —Hasley 12:55, 9 December 2020 (UTC)
  • Support Support Bietels (talk) 14:14, 9 December 2020 (UTC)
  • Support Support Em-mustapha User | talk 15:14, 9 December 2020 (UTC)
  • Support Support DaSupremo (talk) 16:33, 9 December 2020 (UTC)
  • Support Support Nehaoua (talk) 16:42, 9 December 2020 (UTC)
  • Support Support GZWDer (talk) 21:27, 9 December 2020 (UTC)
  • Support Support Ecritures (talk) 22:00, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 02:00, 10 December 2020 (UTC)
  • Support Support - yona B. (D) 08:27, 10 December 2020 (UTC)
  • Support Support Susanna Ånäs (Susannaanas) (talk) 10:57, 10 December 2020 (UTC)
  • Support Support ויקי4800 (talk) 13:00, 10 December 2020 (UTC)
  • Support Support An user intuitive way is needed to avoid anyone to create duplicates in wikidata Viferico (talk) 15:58, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 21:05, 10 December 2020 (UTC)
  • Support Support Higa4 (talk) 04:52, 11 December 2020 (UTC)
  • Support Support Susanna Giaccai (talk) 16:52, 11 December 2020 (UTC)
  • Support Support Arnd (talk) 17:15, 11 December 2020 (UTC)
  • Support Support KasciJ (talk) 18:06, 11 December 2020 (UTC)
  • Support Support Shisma (talk) 19:34, 11 December 2020 (UTC)
  • Support Support Crazy1880 (talk) 19:50, 11 December 2020 (UTC)
  • Support Support Zanaq (talk) 20:34, 11 December 2020 (UTC)
  • Support Support Francois-Pier (talk) 08:39, 12 December 2020 (UTC)
  • Support Support Tom Ja (talk) 09:57, 12 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  13:42, 12 December 2020 (UTC)
  • Neutral Neutral use en:Template:Interlanguage link template which uses syntax {{ill|your article|WD=Q131138}} --Jarekt (talk) 15:16, 12 December 2020 (UTC)
  • Support Support interesting feature Luca.favorido (talk) 19:39, 12 December 2020 (UTC)
  • Support Support. Meiræ 21:56, 12 December 2020 (UTC)
  • Support Support Edgars2007 (talk) 11:10, 13 December 2020 (UTC)
  • Support Support Geagea (talk) 14:06, 13 December 2020 (UTC)
  • Support Support main advantage i see is for readers, as this will enable displaying interwiki links for articles missing in current language, helping multilingual readers to get to the article they are looking for in another wikipedia. while at it, please allow same for redirects, for same reasons. קיפודנחש (talk) 23:05, 13 December 2020 (UTC)
  • Support Support ViktorQT (talk) 13:55, 14 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:57, 15 December 2020 (UTC)
  • Support Support TiagoLubiana (talk) 20:18, 15 December 2020 (UTC)
  • Support Support GiFontenelle (talk) 00:44, 18 December 2020 (UTC)
  • Support Support Golmore (talk) 11:12, 18 December 2020 (UTC)
  • Support Support Heathart (talk) 19:02, 20 December 2020 (UTC)
  • Support Support Fringilla (talk) 20:03, 20 December 2020 (UTC)

Wikidata edit content storage method

Edit proposal/discussion

  • Problem: Wikidata is currently stored item by item.If that happens, the number of edits will increase, and it will be difficult to keep track of the edit history.
  • Who would benefit: all user
  • Proposed solution: I suggest changing to a system that saves several edits together. Editing of "Label", "Description", "Also known as" is treated as one editing even if you edit multiple places. Also, if multiple items are added to one property, it will be one edit. I've given two examples here, but I suggest that you save your Wikidata edits together in addition to this example.
  • More comments:
  • Phabricator tickets:
  • Proposer: Mario1257 (talk) 16:22, 30 November 2020 (UTC)

Discussion

  • As a general principle, data should be recorded at the smallest possible/practical level of granularity. Displaying data can then be done in various ways, including in an aggregated or filtered form. So, I'm inclined to think that perhaps the edit history should be reworked to be smarter about showing edits so that navigation is easier. Silver hr (talk) 03:28, 1 December 2020 (UTC)
  • Mario1257, can you clarify this wish for us? Are you referring to changing and simplifying the user experience, or no? Please get back to us by December 7th. Thanks! —The preceding unsigned comment was added by IFried (WMF) (talk)
    Re-ping Mario1257 since the first one didn't go through. Sorry about that! We have about 24 hours left before voting. MusikAnimal (WMF) (talk) 17:29, 7 December 2020 (UTC)

Voting

  • Support Support BALA. RTalk 01:45, 9 December 2020 (UTC)
  • Oppose Oppose As per my comment in the discussion section. Silver hr (talk) 02:18, 9 December 2020 (UTC)
  • Oppose Oppose As per the comments above by Silver hr. Wallacegromit1 (talk) 10:47, 9 December 2020 (UTC)
  • Oppose Oppose due to decreased granularity Libcub (talk) 20:57, 10 December 2020 (UTC)
  • Oppose Oppose the storage system has been well thought out and developed by countless people, to change this should only happen if the benefits are well thought out, and they aren't in this proposal. Husky (talk) 16:19, 11 December 2020 (UTC)
  • Oppose Oppose due to above discussion Francois-Pier (talk) 09:39, 12 December 2020 (UTC)
  • Oppose Oppose nuff saidKlaas `Z4␟` V:  15:33, 12 December 2020 (UTC)
  • Oppose Oppose! Per Silver hr. Em-mustapha User | talk 15:14, 18 December 2020 (UTC)
  • Support Support AdaHephais (talk) 05:40, 20 December 2020 (UTC)

Show the ORES score of the linked Wikipedia page

Edit proposal/discussion

  • Problem : The ORES quality score of a Wikipedia page is not visible, nor available in Wikidata or Wikidata Query.
  • Who would benefit : Moderators, editors, volunteers, spam fighters, all people maintaining or ameliorating Wikipedia pages, all readers
  • Proposed solution : Show the ORES score in the Wikidata Wikipedia list of pages. The reader could immediately have an impression of the quality of the article in the different languages.The value could also be made available via Wikidata Query. In that case a query could be run for good/bad/mediocre articles, related to a certain domain, instance, or subclass to be able to identify good/bad articles and to ameliorate them. That list could then be used by any tool being able to work with item Q-numbers.
  • More comments: See also:
  • Phabricator tickets:
  • Proposer: Geertivp (talk) 13:27, 21 November 2020 (UTC)

Discussion

  • Question: how are these scores generated and where are they kept? I find it hard to imagine that there are millions of stored numbers, one for every article on every Wiki, and somehow I have not heard of it. Abductive (talk) 11:34, 22 November 2020 (UTC)
    See more at ORES. Geert Van Pamel (WMBE) (talk) 16:25, 22 November 2020 (UTC)
    As I read the description of ORES it is a score for page edits. I see no mention of an ORES score for articles. So I don't understand what is proposed. --Dipsacus fullonum (talk) 14:08, 11 December 2020 (UTC)
    No, there is also models for full article texts in example for enwiki (mw:ORES#Article_quality). --Zache (talk) 06:28, 13 December 2020 (UTC)

Voting

  • Support Support Geert Van Pamel (WMBE) (talk) 19:09, 8 December 2020 (UTC)
  • Support Support CrystallineLeMonde (talk) 20:04, 8 December 2020 (UTC)
  • Support Support automated quality evaluation would be useful as the human-made ones are not updated for years. Keepcalmandchill (talk) 02:44, 9 December 2020 (UTC)
  • Support Support Paul Hermans (talk) 08:21, 9 December 2020 (UTC)
  • Support Support Abductive (talk) 09:15, 9 December 2020 (UTC)
  • Support Support Wallacegromit1 (talk) 10:42, 9 December 2020 (UTC)
  • Support Support Kpjas (talk) 11:25, 9 December 2020 (UTC)
  • Support Support Yes. I create worklists for Wikipedia articles and currently have an onerous workflow querying the API through OpenRefine to get page assessment, parsing it, then pasting the table back into user space. It would be so much better if there was a way to access the Wikipedia page ORES score (not Wikidata ORES score) through Wikidata so I can just extract it with Listeriabot. DrThneed (talk) 00:49, 10 December 2020 (UTC)
  • Support Support Being able to query Wikipedia articles for their ORES scores would be very useful when organising projects and editing events. Giantflightlessbirds (talk) 03:51, 10 December 2020 (UTC)
  • Support Support Steven Sun (talk) 02:27, 11 December 2020 (UTC)
  • Oppose Oppose No ORES score for articles. See the discussion above. --Dipsacus fullonum (talk) 14:10, 11 December 2020 (UTC)
  • Oppose Oppose No. --Kusurija (talk) 18:40, 11 December 2020 (UTC)
  • Support Support Helder 09:46, 12 December 2020 (UTC)
  • Support Support Xavi Dengra (MESSAGES) 16:57, 13 December 2020 (UTC)
  • Support Support Cesc97 (talk) 19:27, 13 December 2020 (UTC)
  • Support Support AdaHephais (talk) 05:41, 20 December 2020 (UTC)

Display reference in edit summary when a reference is added

Edit proposal/discussion

  • Problem: The edit summary for this diff does display that a reference was added, but not which reference it is. References can be unreliable, spam links etc. so having them be easy to monitor is desirable.
  • Who would benefit: People who patrol Wikidata items for problematic edits, since the content of the diff is immediately displayed.
  • Proposed solution: Add the content of the reference to the edit summary; in this case it would be "Added reference (imported from:English Wikipedia) to claim: mountain range (P4552): Andes (Q5456)"
  • More comments: I hope that this isn't too late, it's a repost of two similar requests in the preceding years. This feature would be useful as well if it displayed in crosswiki watchlists. There may be length issues when the reference is long.
  • Phabricator tickets:

Discussion

Voting

Creation of new objects resp. connecting to existing objects while avoiding duplicates

Edit proposal/discussion

  • Problem: The problem of connecting newly created articles to existing objects respectivley creating new objects for unconnected pages (when, how, by whom, ...) for hundreds of newly created articles per day in different language versions, and how to avoid duplicates amongst the currently 90 million objects, has been discussed for years again and again without a real solution, for example at d:Wikidata:Requests for permissions/Bot/RegularBot 2
  • Who would benefit: Improved data quality, i.e. less duplicates
  • Proposed solution:

At d:Wikidata:Contact_the_development_team/Archive/2020/09#Connecting_newly_created_articles_to_existing_objects_resp._creating_new_object_-_additional_step_when_creating_articles,_categories,_etc. a possible solution has been discussed:

An additional step after saving a newly created article etc. to present to the user a list of possible matching wikidata objects (e.g. a list of persons with the same name; could be a similar algorithm as the duplicate check / suggestion list in PetScan, duplicity example) or the option to create a new object if no one matches (depending one the type of the object, some values could be already be pre-filled and pulled from the article, e.g. from categories or infoboxes). From my point of view, one current problem is, that a lot of creators of articles, categories, navigational items, templates, disambiguations, lists, commonscats, etc. are either not aware of the existance of wikidata or did forget to connect a newly created article etc. to an already existing object or to create a new one if not yet existing, which might lead to (more) duplicates, if this creation respectivley connection is not done manually, but by a bot instead, which have to be merged manually afterwards.

In addition, there could be specialized (depending on the type of the objects, e.g. one bot for humans, one for films, one for building, etc.) bots, which are for example able to check for various IDs (like GND, VIAF, LCCN, IMDb, ...) in order to avoid creating duplicates and creates new items or connects matching items based on IDs.

Also, if someone uses the "translation function" to create a translated article in another language version, then the new translated article could be connected automatically to the object of the original article. And after a version import (after a translation), at the moment often the link to the Wikidata object gets lost and the article has to be reconnected again a second time manually.

  • More comments:
  • Phabricator tickets:
  • Proposer: M2k~dewiki (talk) 03:33, 17 November 2020 (UTC)

Discussion

  • Just to give the scope of the problem if nothing is done: I needed several months to integate 2,000 items wihout P31/P279 that had accumulated in biochemistry from freshly created en-WP articles. Wikipedia editors are left alone with the task of creating WD items for their articles. I am now facing 1,000 more items from de-WP articles. Any guidance that can be given to WP editors will be helpful. --SCIdude (talk) 08:05, 17 November 2020 (UTC)
  • We already have constraints that flag items with non-unique IDs. I don't think that those cases should be automatically resolved by bots and in any case bots are created by the community and don't need to be created by the community wishlist team.
I don't think the way to make Wikidata more popular is to force Wikipedia editors to do the work of interfacing with Wikidata when they create new articles. I don't think either dewiki nor enwiki would activate such a feature if it would be available to them. ChristianKl❫ 15:33, 17 November 2020 (UTC)
On the contrary, a whole heck of a lot of opposition at en.WP is precisely because the integration is so loose. Integration rolled out before support for client watchlists was provided (and then after the amount of changes were too much so the devs scaled that back). --Izno (talk) 18:14, 17 November 2020 (UTC)
  • This is probematic - how can system say "this article should be connected with this item?" But easy solution should be hey, on Wikidata is item with smae label as your article without sitelink to this wiki. Is it the same? And this system needs some modifications, e.g for wikisource, where "The Book" is ususally not the same thing as "The Book" on Wikipedia, but only edtion. JAn Dudík (talk) 15:11, 18 November 2020 (UTC)

Voting

  • Support Support This would be nice - tighter integration between the wiki's and wikidata generally. ArthurPSmith (talk) 16:02, 9 December 2020 (UTC)
  • Support Support Dhx1 (talk) 12:59, 11 December 2020 (UTC)
  • Support Support Thadguidry (talk) 15:12, 11 December 2020 (UTC)
  • Support Support  Klaas `Z4␟` V:  13:45, 12 December 2020 (UTC)
  • Support Support WeHaKa (talk) 23:37, 14 December 2020 (UTC)
  • Support Support EncycloABC (talk) 18:33, 18 December 2020 (UTC)
  • Support Support AdaHephais (talk) 05:41, 20 December 2020 (UTC)
  • Support Support Wotheina (talk) 12:21, 21 December 2020 (UTC)

New batch edit API

Edit proposal/discussion

  • Problem: Currently when someone edits 1000 times, WDQS update is invoked 1000 times.
  • Who would benefit:
  • Proposed solution: We need to introduce a new API to do batch edits. See d:User_talk:BrokenSegue/API_Proxy#Batch_edit_API for more information.
  • More comments:
  • Phabricator tickets:
  • Proposer: GZWDer (talk) 06:19, 26 November 2020 (UTC)

Discussion

  • @GZWDer: Could you elaborate on the issue? What is the problem with 1000 WDQS updates? How should the "batch edit API" work? Are you proposing, for example, to make the same change to 1000 items at the same time? Apologies for my ignorance, I admit I'm not the most Wikidata-savvy. I'm hoping a little clarification will benefit voters, too, and not just me :) Thanks, MusikAnimal (WMF) (talk) 22:36, 2 December 2020 (UTC)
    • WDQS currently reload an item when it is edited. So when an item is edited 100 times, it must be reloaded 100 times. Moreover, many small reloads is more expensive than a large one.--GZWDer (talk) 12:35, 3 December 2020 (UTC)
  • I have a plan to import more than 200 million (scientific articles) items. However, currently we need seven years to complete this if we do one edit every second.--GZWDer (talk) 21:25, 9 December 2020 (UTC)

Voting

  • Support Support Libcub (talk) 20:58, 10 December 2020 (UTC)
  • Support Support Redalert2fan (talk) 00:22, 12 December 2020 (UTC)
  • Support Support not a big fan of bot edits, though Klaas `Z4␟` V:  15:19, 12 December 2020 (UTC)
  • Support Support Cesc97 (talk) 19:28, 13 December 2020 (UTC)
  • Support Support QuickStatements is slow and tends to randomly fail. Current experience of mass-editing is miserable, developers implicitly penalize active users by introducing more and more rate limits. Come on, since 2013 I did not see a single improvement in this direction, only restrictions. And I perfectly understand that "batch edit api" is not just "yet another api on top of existing primitives". This should be a targeted pipeline redesign, not necessarily starting with "bulk" part, for example, starting with introduction of non-bulk operations commonly used in QuickStatements, like "atomically insert statement with references and qualifiers, or update existing statement, if any". That's my only vote. Other proposals are definitely cool, but would kill Wikidata due to growing user base, as more users will just peck existing APIs until denial of service. Lockal (talk) 16:29, 16 December 2020 (UTC)
  • Support Support EncycloABC (talk) 18:37, 18 December 2020 (UTC)

Human readable wikilinks to Wikidata query service

Edit proposal/discussion

  • Problem:

Wikidata query service result links to WMF wikipages are rendered as urlencoded URLs. The urlencoded page titles aren't human readable. Full URLs are also consuming so much screen space that the common problem is that result rendering will be failbacked to single column mode and result is not rendered as a table.

  1. Example of problematic result: https://w.wiki/jgK
  2. Example url value: <https://fi.wikipedia.org/wiki/Min%C3%A4_ja_Morrison>
  • Who would benefit:

All users who are querying links to Wikimedia wiki pages using Wikidata Query Service.

  • Proposed solution:

Add SPARQL prefix for WMF wikis OR change the the HTML rendering so that the rendered link would be like <wp:fi:Minä_ja_Morrison> in the result view.

Example result: https://w.wiki/jyS

  • More comments:
  • Phabricator tickets:
  • Proposer: Zache (talk) 05:56, 28 November 2020 (UTC)

Discussion

Voting