Community Wishlist Survey 2021/Wikidata

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Wikidata
23 proposals, 64 contributors
The proposal phase has ended.
Come back on December 8 at 18:00 UTC to vote on proposals!



Bibliographical references/sources for wikidataitems

Edit proposal/discussion

  • Problem:

Items (e.g. buildings, archeological sites, paintings, artists ...) described on various wikimedia platforms benefit largeley 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 on all languages of Wikipedia and knowdlegde remains "unused" and "undiscovered".

  • Who would benefit:

Editors on wikipedia, user community in general (more availiable sources = better articles), all the readers

  • Proposed solution:

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 is automatically available in each language. For example one could use this to link 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 informationcommunity
    4. link between scientific research and valorisation of knowdlege 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)

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)

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

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

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

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)

Search Wikidata items from Lua

Edit proposal/discussion

  • Problem: There is impossible to look for Wikidata item if no article is associated with the item. However many of the items are filled with properties of type 'external identifier'. The identifiers are mostly (I hope) unique by design. I wish to use them for searching.
  • Who would benefit: Template designers.
  • Proposed solution: Provide new API function in Lua interface: mw.wikibase.getEntityIdForExternalId( propertyId, externalIdValue )
  • More comments: The ability for searching gives us opportunity to create generic citation template, which might be easier to use.
  • Phabricator tickets:
  • Proposer: Paweł Ziemian (talk) 23:09, 27 November 2020 (UTC)

Discussion

  • @Paweł Ziemian: I'm not sure I quite understand. Do you mean for when you want to use Wikidata in a page with no sitelink, but you do have an external identifier? In that situation, why wouldn't you be able to use a Wikidata ID instead? That could then be used to retrieve the external ID as well as anything else. You mention a generic citation template — is something like {{Cite Q}} what you have in mind? —Sam Wilson 00:17, 4 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)

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

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)

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)

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

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)

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

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

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!

Create the Legislative Branch section in the country templates

Edit proposal/discussion

español: Crear el apartado de Órgano Legislativo en las plantillas de países

  • Problem: This proposal arises from the advantage of having a section for the legislative body in the Country File, since currently to indicate it it is mandatory to access WikiData.
español: Esta propuesta surge de la ventaja que es tener un apartado para el órgano legislativo en Ficha de País, ya que actualmente para indicarlo es obligatorio acceder a WikiData.
  • Who would benefit:
  • Proposed solution: In the way that I propose it, it would be as simple as accessing the Country File template and adding the code / section of the legislative body (org_leg).
español: De la manera que lo propongo sería tan sencillo como acceder a la plantilla de Ficha de País y añadir el código/sección de órgano legislativo (org_leg).
  • More comments:
  • Proposer: MetroVal (talk) 10:18, 25 November 2020 (UTC)

Discussion

  • @MetroVal: ¡Hola! No entiendo de qué se trata esto. ¿Podría proporcionar algunos enlaces a ejemplos? Gracias, MusikAnimal (WMF) (talk) 16:46, 28 November 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)

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)

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

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)

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)

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)