Community Wishlist Survey 2019/Wikidata

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2019

Wikidata
19 proposals, 130 contributors, 304 support votes

Go-previous.svg Watchlists  •  Wikisource Go-next.svg

Contents


Solution to the ‟Bonnie and Clyde” problem

Support Edit proposal/discussion

  • Problem: Wikidata can only link one article per language. There are, however, cases where a single article in one language corresponds to two articles in some other language. A prototypical instance is Bonnie and Clyde, with most languages having an article about the duo Bonnie and Clyde, some having an article about Bonnie Parker, and some having an article about Clyde Barrow (see also d:WikiProject Cross Items Interwikis). The articles about the individual bank robbers cannot (at least not both) link to the many articles about the duo, which exist in many languages, so it is hard to find the corresponding articles in those other languages when coming from such a single-person article. (Other relevant situations I can think of are misfitting taxonomies; while e.g. in biology the international research community has agreed upon a common hierarchy, this is not the case in many other fields, where it might turn out to be unclear or questionable which term in another language an article should be linked to when there is no perfect match.)
  • Who would benefit: Potentially all readers, exact number of relevant cases unknown so far
  • Proposed solution: While allowing Wikidata items to link more than one page per language is probably not a viable option, having language links as displayed in Wikipedia side-bars link to more than one article in another language should be principally possible. A language link to a language version in which more than one article is linked to the current one could, for instance, show a pop-up menu instead of directly navigating to the foreign-language article in question. More important than the GUI design for this feature would be the question where to take the target articles from. In the case of Bonnie and Clyde, a language link connecting Bonnie Parker articles (or Clyde Barrow articles, respectively) with Bonnie-and-Clyde articles could be obtained from the ‟part of” relation (d:P361). A sufficiently general solution would perhaps allow for a set of relevant Wikidata relations, to be determined by the Wikidata community, that are used to populate ‟multiple” interwiki connections of the proposed form. Even if the ability to have ‟multiple” interwiki connections is undesired, the Wikidata relations could still be used to connect articles to languages for which a direct equivalent has not yet been registered in Wikidata (either because a corresponding artcile has not yet been linked or because such a corresponding article does not yet exist).
  • More comments:
  • Phabricator tickets: T54564
  • Proposer: Lothar Scherners (talk) 17:04, 8 November 2018 (UTC)

Discussion

  • Well, there is Community Wishlist Survey 2019/Wikidata/Allow non one-to-one correspondence relationship in wikidata and display them in interlanguage link also. --Izno (talk) 00:15, 9 November 2018 (UTC)
    • I am unadopting that proposal in order to adopt another proposal, now that someone have created a similar proposal. If someone think the proposal that I wrote would be better than this proposal then they're welcome to adopt it. C933103 (talk) 01:20, 9 November 2018 (UTC)
  • I don't think P361 is sufficient for determine the display of multi interlanguage link. For instance New York is Part of the USA but I don't think many would want to see such interlanguage link when there are no direct correspondence. Additional properties could be created for situation that would match this. C933103 (talk) 01:32, 9 November 2018 (UTC)
  • What about phab:T206426 way instead? By this way we don't need to "regard" generally all redirects. --Liuxinyu970226 (talk) 11:32, 11 November 2018 (UTC)
    • phab:T206426 is only for multilingual wiki, not general wikipedia projects. C933103 (talk) 15:26, 13 November 2018 (UTC)
      • @C933103: But in the last year Survey you also suggested that the T206426 solution should also work on monolingual wikis that use multiple scripts (e.g. Min Dong Chinese Wikipedia), or am I remember somewhat wrong? --Liuxinyu970226 (talk) 04:17, 17 November 2018 (UTC)
        • The solution to this ticket can be expanded to cover multilanguage wiki scenario however the ticket itself is just that.C933103 (talk) 04:19, 17 November 2018 (UTC)
  • And, why is this section shown twice on Community_Wishlist_Survey_2019/Miscellaneous? --Liuxinyu970226 (talk) 11:33, 11 November 2018 (UTC)
  • If this is done, I think it would also be beneficial to fix these links for wikis which use multiple different untranslatable scripts or dialects (i.e. wikis which use permanent duplicated item (P2959)), perhaps by allowing a set number of interwikis for each wiki (e.g. one each for hak-Hant and hak-Latn). Jc86035 (talk) 12:31, 11 November 2018 (UTC)
  • Given that the AfC for allowing redirect was just closed, it's now possible to solve one way of the Bonnie-and-Clyde problem.
I don't think the other way should be done via a property based way. Lets say we have en:"Bonnie"->de:"redirect:Bonnie-and-Clyde" and en:"Clyde"->de:"redirect:Bonnie-and-Clyde" but no existing link from the de:"redirect:Bonnie-and-Clyde" to English. We could have a plugin that provides a page that lists en:"Clyde" and en:"Clyde" that gets automatically generated (e.g. no Wiki page) when a user clicks on `English` in the interwikilink list. ChristianKl❫ 18:38, 14 November 2018 (UTC)
  • Another example could be lists such as List of something A to E on xy.wiki and List of something A–C on yx.wiki. (Same list, but different alphabetic seperation into sub-lists.) I've noticed couple of articles/items like this, these lists often doesn't have any interwiki. But it might be comment for other discussion. Regards, — Draceane talkcontrib. 21:51, 18 November 2018 (UTC)

FYI: The Wikidata folks say that they could commit to analyze and solve the problem, but not necessarily with the solution offered here. Ryan Kaldari (WMF) (talk) 23:08, 14 November 2018 (UTC)

See also Community Wishlist Survey 2019/Wikisource/Create integrated interwiki mechanism for Wikisource for a specific aspect of this problem. Cheers, VIGNERON * discut. 12:37, 18 November 2018 (UTC)

Voting

  • Oppose Oppose I think that we should find a way to deprecate P2959 instead. --Liuxinyu970226 (talk) 04:18, 17 November 2018 (UTC)
    • The problem of P2959 related to, however independent from, the problem we are talking about here. With a full overhaul to the wikidata structure, both problems will be solved immediately, however it seems like no one is actually willing to spend serious efforts on improving wikidata, I guess we have no other choice than to accept that only minor improvement will be made and hope that it will become more useful after accumulating all the minor improvements after a decade or so. From this perspective, the proposal doesn't goes against resolving the problems related to P2959. Hence Support Support C933103 (talk) 07:04, 17 November 2018 (UTC)
  • Support Support Jc86035 (talk) 10:47, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 11:38, 17 November 2018 (UTC)
  • Support Support Walter Klosse (talk) 13:28, 17 November 2018 (UTC)
  • Support Support JAn Dudík (talk) 20:33, 17 November 2018 (UTC)
  • Support Support Zabia (talk) 10:15, 18 November 2018 (UTC)
  • Partial Support Support. I support this proposal in the sense that the issue needs to be looked into and be resolved within reasonable time, yet not necessarily in the exact same manner as suggested by the proposal. --Beat Estermann (talk) 16:33, 18 November 2018 (UTC)
  • Support Support Per Beat Estermann — Draceane talkcontrib. 17:21, 18 November 2018 (UTC)
  • Support Support Dvorapa (talk) 19:23, 18 November 2018 (UTC)
  • Support Support Per Beat Estermann Pharos (talk) 05:43, 19 November 2018 (UTC)

One-click solution to show qualifiers and references in wikidata SPARQL-queries

Support Edit proposal/discussion

  • Problem: It is a great experience and big advantage to browse wikidata using the query helper. For the unexperienced user it is difficult to see what qualifier, rank and sources the data have. This makes it difficult to explore the data for users without or with little SPARQL-knowledge.
  • Who would benefit: Showing the sources in queries would make it easier to see what part of the statements is for example sourced. This would help to estimate the reliability of the statements of the property and may increase the acceptance of the data in other wiki projects. On the other side further use and operations could be made, if for example one can see all the available qualifiers (like "point in time" etc.).
  • Proposed solution: In the query-builder there is already a button to add a label for the required property. One additional button should add the unit, the rank, all the qualifiers and all the references to the result of the query.
  • More comments:
  • Phabricator tickets:
  • Proposer: Datawiki30 (talk) 21:37, 7 November 2018 (UTC)

Discussion

  • Just a comment that this proposal may be more complex than it seems: the simple queries without qualifiers etc. refer to a different triple structure than the complete queries would, and that transformation may be hard to automate. ArthurPSmith (talk) 16:43, 17 November 2018 (UTC)

Voting

Improvements to the reliability of Wikidata

Support Edit proposal/discussion


  • Problem: Wikidata is often considered unreliable as a data source due to vandalism and a lack of adequate sourcing. In spite of these issues, Wikidata is still used in infoboxes across Wikipedias, even though it can be difficult for Wikipedia editors to edit Wikidata; and on many wikis references are omitted entirely from Wikidata infoboxes, making it more complicated to check the veracity of data.
  • Who would benefit: Wikidata; Wikipedia articles (infoboxes, descriptions, external database links, etc.) and other users of Wikidata data
  • Proposed solution: In order to verify existing data, it would be helpful to make sure that references used in Wikidata are shown when statements are used in Wikipedia infoboxes and the like,[note 1] and it could also be helpful to allow editors of both Wikipedia and Wikidata to add maintenance tags with a script (e.g. "[this statement] might not be true" or "needs a source"), replicating the utility of Wikipedia's venerable [citation needed]-style tags. Particularly for data which can't be verified easily using secondary sources or constraint violations, like geographic coordinates, it would also be beneficial to have tools to easily find errors (e.g. wrong coordinates) or oddities (e.g. weird precision) in the data.

Notes

  1. This would probably involve editing the Wikidata-related Lua modules for each wiki, or by creating a new module to incorporate all their features and localizing it across all wikis (there are currently multiple disparate modules in use, even on individual wikis).
  • More comments: Originally page protection enhancements were part of this proposal. These are now part of a separate proposal.
  • Phabricator tickets:
    • phab:T209242 – For Lua modules across Wikipedias, allow display of sources from Wikidata and filtering of unreferenced statements across all Wikidata infoboxes (11 November 2018)
    • phab:T209237 – Gadget for Wikidata and Wikipedia users to add maintenance tags to Wikidata items (11 November 2018)
    • phab:T209241 – Creation of software to auto-detect errors or oddities in internal or unreferenceable Wikidata statements, e.g. images, geographic coordinates (11 November 2018)
    • Related: phab:T148928 – Wikidata integration for proveit gadget (23 October 2016)
  • Proposer: Jc86035 (talk) 20:24, 29 October 2018 (UTC)

Discussion

Many of the comments discuss page protection because it was originally part of the proposal before being split into Partial and multi-item protection for Wikidata items. Jc86035 (talk) 16:28, 16 November 2018 (UTC)

Voting

Freely editable input mask

Support Edit proposal/discussion

  • Problem: Very often there is a need to create new Items of a similar kind, series of Items. For example a roster of team members, works by an artist or so on. This is actually only possibe, when I create for every Item from the beginning a new Item, where I have to do it alway from the beginning. This needs a relly long time. Or I have to use external helpers and concepts, so Google or Excel. Even this is time robbing.
  • Who would benefit: All contributors to Wikidata, who need to create similar items in a row.
  • Proposed solution: Magnus Manske already created Cradle. This is nearly exactly what is needed - problem: after the first few days there are problems with saving the new items. So here would be an input mask for ancient potters and vase painters. Here for a single piece of ancient pottery. This must be imlemented in the normal Wikidata structure. Every user must can create their own masks - as much masks they need for use and reuse.
  • More comments:
  • Phabricator tickets:

Discussion

  • I believe we need something as "create as" or "create like" having the possibility to duplicate Labels, Descriptions, and Statements from another similar entity in a controlled way without the risk of creating rubbish content. I often do this already now but completely manual, which is taking a lot of time and effort. Geert Van Pamel (WMBE) (talk) 10:56, 4 November 2018 (UTC)
  • Another problem is duplicating e.g. the name of a person in all languages. The name of a person generally is language independent. When the name of a person is already entered for one language it must not be overwritten. When the name of a person is unavailable in one language it cannot be searched (in that language). Geert Van Pamel (WMBE) (talk) 10:56, 4 November 2018 (UTC)
  • I had exactly the same request. The current stucture is very versatile but not always the most user-friendly nor the most efficient. At least not at the same level of what dedicated data models forms could provide. In example, for alloys, alloying elements have to be specified adding "has part" property then "Chromium" (i.e.) item and then adding the qualifier "Proportion", then adding the numerical value and then adding the unit... Seriously... With a dedicated form you just choose the element and write numerical value. When you have alloys with 10+ elements you save a trendemous amount of time. Not saying that newcomers will immediately understand how to deal with this type of form while they would have no idea on how to do it unless they find the materials project page and read everything. This type of dedicated form has the potential to greatly enhance the contributions to Wikidata by empowering current users and easing the adoption by new users. --Thibdx (talk) 23:54, 4 November 2018 (UTC)
  • What is wrong with d:WD:QuickStatements? --Izno (talk) 01:44, 6 November 2018 (UTC)
    QuickStatements is an "external" tool which has its own merits, and potential risks; what we want here is something internal to the main Wikidata Web GUI, that allows to create new "similar" data items based on a chosen item profile which lists typical properties with default values. And a constraint violation technique (or warning) to prevent "mass" creation of duplicate items/statements. Geert Van Pamel (WMBE) (talk) 10:12, 8 November 2018 (UTC)
  • User:Marcus Cyron, what do you mean with "after the first few days there are problems with saving the new items"?
    • Hi. As I wrote, there's nothing more behind it. For two days or so, Cradle worked very well, but since then it did not safe the data. You can work on Cradle, put everything on the sheet - but in the moment you wanna safe it, it did not safe. At first it helps to go from Firefox to Chrome - but also two days later I tinh it was also not longer able to safe. And this not only for me. But what Magnus has shown it, that it definetly would work. Marcus Cyron (talk) 06:41, 9 November 2018 (UTC)

Voting

Expand automatic edit summaries

Support Edit proposal/discussion

  • Problem: When one's 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: This is a repost of Community Wishlist Survey 2017/Wikidata/Expand automatic edit summaries as I still think it could greatly increase the usefulness of Wikidata.
  • Phabricator tickets: phab:T108688; phab:T171027 may be worth paying attention to since it's a technical issue that could impact on this project.

Discussion

Voting

Display reference in edit summary when a reference is added

Support Edit proposal/discussion

  • Problem: Repost since this is still a 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. 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

The notification view should show the label for an item instead of showing the item ID

Support Edit proposal/discussion

  • Problem:
    Notifications.jpg
    Given that I don't know which item has which numbers this view isn't very informative. It would be a lot more informative if it would show the label of the items in the list.
  • Who would benefit: Everyone who works on Wikidata in a way that they get notifications.
  • Proposed solution: Show the labels of the items instead of showing the ID.
  • More comments:
  • Phabricator tickets:

Discussion

Voting

More fine-grained diffs for Wikidata

Support Edit proposal/discussion

  • Problem: Wikidata diffs (item changes views) are currently only show which statement/reference/description/etc. changed, they don’t highlight what exactly changed within it. For example, in this diff, only one word was changed (the first one in the parentheses), but the whole description is highlighted with the same style which shows the actually changed parts on wikitext pages. (I had to use Navigation Popups to find the actual changes.) Here only the first snak changed, but the whole reference is highlighted (more or less). (The hash is also different; I don’t know if it’s because of the bot edit.) Here only the day changed, but nothing is highlighted(!).
  • Who would benefit: Wikidata users patrolling edits.
  • Proposed solution: Create more fine-grained diffs.
  • More comments: For string values (including labels/descriptions/aliases as well as string/external identifier/URL/formula/etc. datatypes), it seems pretty easy as the wikitext diff engine can be reused. Time and quantity values are a bit trickier, but even more needed, as it’s much harder to use an external diff software. It doesn’t make any sense for entity values such as item, property, lexeme etc.
  • Phabricator tickets: Any? It’s quite hard to search for this on Phabricator.
  • Proposer: Tacsipacsi (talk) 21:28, 10 November 2018 (UTC)

Discussion

Voting

Date handling improvements – additional precision and correction of translations in interface

Support Edit proposal/discussion

  • Problem: On Wikidata, it is still not possible to add dates with precision better than the day or dates with time zone information, which prevents Wikidata from accurately recording when events occurred; and dates are still incorrectly localized for most languages (e.g. "4 8 1961" in Chinese), which obviously impedes a lot of contributors in understanding what they actually mean. These issues can harm the ability of editors to add data, making them problematic for data consumers as well.

    While "data entry is impossible" is self-explanatory, it's probably worth explaining just how complicated and irritating the date formatting issues are. On Wikidata dates can be shown with different precisions, from "day" (the current limit) to a billion years. Each of those precisions has to be translated correctly, and BC dates and AD years before 100 should be handled specially. This doesn't really work right now – "2 January [in] 1 AD" is shown as "1. január 2" in Hungarian (interpreted by readers as first of January in the year 2), and it's obviously even worse without displayed month names. Centuries and decades are also shown haphazardly in several languages because the software doesn't allow for things like grammatical inflection, though this is more of an irritant than an impediment.

    Although these are nominally separate issues, fixing either of them would involve changing the way Wikidata's interface handles dates, so it could be more effective for them to be worked on in tandem, and it would avoid duplication of work.

  • Who would benefit: primarily Wikidata contributors
  • Proposed solution: fix the irritating UI problems; add functionality which is needed to enable data entry and data storage
  • More comments:
  • Phabricator tickets: Selection of some tickets. I have added bold to the ones that seem the most impactful. I'm not expecting all of them to be resolved but it would be nice if work could be done on all of them.
    • phab:T57755 – Allow time values more precise than day (15 October 2013)
    • phab:T63909 – Make use of before and after in Time datatype (25 February 2014)
    • phab:T63958 – Use existing $dateFormats to format dates on Wikidata (26 February 2014)
    • phab:T95553 – Full stop in messages such as Wikibase-time-precision-century is incorrect in English (9 April 2015)
    • No tickets yet:
      • Translate date formats correctly
      • Correct grammatical inflection for dates (e.g. decades in Hungarian)
  • Proposer: Jc86035 (talk) 08:38, 30 October 2018 (UTC)

Discussion

Originally this proposal was broader in scope, so many of the comments discuss separate issues. Jc86035 (talk) 11:51, 17 November 2018 (UTC)
  • Allowing date/times more precise than 1 day will have to make some provision to distinguish all the existing dates, which in reality are in local time (despite what documentation says), from dates created after the implementation, which would need a time zone. Jc3s5h (talk) 11:25, 19 November 2018 (UTC)

Voting

  • Support Support Jc86035 (talk) 05:20, 17 November 2018 (UTC)
  • Support Support, however I would like to use this opportunity to express my disappointment against the limited ability of the community tech team which lead to the rejection of many aspects of this proposal and also many other proposals. Especially with the amount of donation WMF have been gathering from users each year. C933103 (talk) 06:43, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:44, 17 November 2018 (UTC)
  • Support Support Shisma (talk) 12:30, 17 November 2018 (UTC)
  • Support Support wikidata definitely should handle date/time better, it's an important datatype for many purposes. ArthurPSmith (talk) 16:41, 17 November 2018 (UTC)
  • Support Support Micru (talk) 17:04, 17 November 2018 (UTC)
  • Support Support Thibdx (talk) 17:58, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:22, 18 November 2018 (UTC)
  • Support Support Jklamo (talk) 03:42, 18 November 2018 (UTC)
  • Support Support Psychoslave (talk) 04:20, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 11:00, 18 November 2018 (UTC)
  • Support Support Viswaprabha (talk) 23:35, 18 November 2018 (UTC)
  • Support Support Sabas88 (talk) 09:08, 19 November 2018 (UTC)
  • Support Support Zeromonk (talk) 09:27, 19 November 2018 (UTC)
  • Support Support Dhx1 (talk) 12:48, 19 November 2018 (UTC)
  • Support Support Geraki TL 14:01, 19 November 2018 (UTC)
  • Support Support Hibm98 (talk) 16:52, 19 November 2018 (UTC)

Gather metadata of ISO/ASTM/EN... standards

Support Edit proposal/discussion

  • Problem: We do not have items for many ISO/ASTM/EN... standards. This is usefull for projects because these standards list the official names and definition of some other items such as material properties.
  • Who would benefit: Wikidata projects and the community as a whole.
  • Proposed solution: Write a script that crawl ISO/ASTM/CEN sites for standards metadata.
  • More comments:
  • Phabricator tickets:
  • Proposer: Thibdx (talk) 17:27, 11 November 2018 (UTC)

Discussion

Voting

  • Support Support Libcub (talk) 11:41, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:46, 17 November 2018 (UTC)
  • Oppose Oppose; there is basically nothing for Community Tech to do here – users can already import this data themselves, and there aren't so many new standards that a bot is required to import new standards every five minutes. Jc86035 (talk) 15:47, 17 November 2018 (UTC)
  • Support Support There is 22400 ISO standards + 13000 specific ASTM standards + 8000 SAE specific aeronautic standards + .... I couldn't find the quantity of specific EN standards. AFNOR list 100 000 standards valid in Europe.The 22400 ISO standars have to be priority since these are valid worldwide. Thibdx (talk) 18:14, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:22, 18 November 2018 (UTC)
  • Support Support Krokofant (talk) 05:49, 19 November 2018 (UTC)
  • Comment Comment @Thibdx: I already have a simple scrapy script that dumps ISO data into a CSV file. The time consuming part is not having a model for ISO standards, and not having an easy and efficient way to write data back into Wikidata (one edit per item with multiple statements, not Pywikibot's one edit per minor change). You can copy and have a look at the spider (especially the xpath rules) at [1]. Dhx1 (talk) 12:46, 19 November 2018 (UTC)

Partial and multi-item protection for Wikidata items

Support Edit proposal/discussion

  • Problem: (by Man77) It is (still) my firm opinion that the control of incoming data and of changes to the data stored in Wikidata does not work as well as it should. What is a tiny edit on one of Wikidata's ~ 52 million items can cause wrong information to appear in many thousands of pages in more than a hundred other projects, even those which chose to have flagged revisions as part of their quality control. There are many examples where the threat of vandalism not being detected is significantly higher than the possibility that the information provided actually needs to be changed (for instance: Chiapas is located in Mexico); some information is actually timelessly true (such as population numbers from a census at a specific date in time). Allowing such stable data to be actually stabilized and only be changed under circumstances yet to be defined could not only increase Wikidata's reputation as a trustworthy database but also increase its usage, while reducing its vulnerability.

    (added by Jc86035) Wikidata's core editor base is also quite small in spite of the large amount of content, and unlike on other projects, some items may never be edited manually because of the breadth of this data. Directly because of this, some vandalism can go unnoticed for months. On the other hand, it would be impractical and problematic to e.g. semi-protect large groups of items in their entirety, because this would prevent a lot of page moves and deletions from being reflected on Wikidata by the user performing the page move or deletion, and it would prevent anonymous and new contributors from adding valuable data (particularly translations of labels and descriptions).

  • Who would benefit: Wikidata as a whole (reputation, usage), Wikidata volunteers, other projects' volunteers (lessened workload), readers (wouldn't see wrong information)
  • Proposed solution: Allowing partial protection of items, and protection of classes of statements across all Wikidata items based on their content (i.e. usage of properties, qualifiers and references), would help with preventing needless vandalism. Users might be deterred from vandalizing (due to the additional effort required) or might be encouraged (or forced) to discuss potentially problematic changes with other editors.
  • More comments: Originally flagging of problematic statements was part of this proposal's solution. This is now part of a separate proposal.
  • Phabricator tickets: T189412, T209243
  • Proposer: → «« Man77 »» [de] 15:12, 11 November 2018 (UTC)

Discussion

  • @Man77: This is quite similar to part of my proposal (page protection for classes of statements and statements with references; gadgets for WP and WD users to add maintenance tags). I think it might be beneficial to either merge the proposals together or distinguish them in their aims, due to the rule that only the top ten proposals will certainly be looked at. Jc86035 (talk) 16:05, 11 November 2018 (UTC)
    I did not realize your proposal was rather similar to my idea. Please feel free to merge them. → «« Man77 »» [de] 16:19, 11 November 2018 (UTC)
    • The other proposal is too sprawling, so we're going to close that one but retitle this one to mention the solution suggested in the other. Hope that makes sense. Ryan Kaldari (WMF) (talk) 23:43, 14 November 2018 (UTC)
      @Ryan Kaldari (WMF): Would it be fine to only keep the parts of the proposal focused on issue tags and showing references with the Wikidata Lua modules? There are clearly at least a few editors (who I did not canvass) who think the topic is important, so I think it would be somewhat inappropriate to close it outright; and I think those things would be fairly doable. Jc86035 (talk) 06:20, 15 November 2018 (UTC)
      Sure, if it's trimmed down to be more focused, we can keep it. Ryan Kaldari (WMF) (talk) 21:07, 15 November 2018 (UTC)

User:Meno25 User:P.geisler User:Alexmar983 User:Pipetricker User:Tacsipacsi User:Ecritures User:Jdx User:Richard Nevell (WMUK) User:Mike Peel User:Higa4 User:Rachmat04 User:Hummingbird User:Pescov User:Termininja User:Emir of Wikipedia User:Cybularny User:Wolbo User:Wostr User:Jo-Jo Eumerus User:Superchilum User:WhatamIdoing User:Jklamo User:Sahaquiel9102 User:Veneziano User:M11rtinb User:Meisam User:Joalpe User:Thomas Obermair 4 User:ArthurPSmith User:Iliev User:Laboramus User:Jianhui67 User:Liuxinyu970226 User:Tgr User:Rschen7754 User:Ederporto Notifying everyone who supported the similar proposal from last year (all issues still apply, although the proposed solution's focus is narrower and more feasible). Jc86035 (talk) 15:12, 17 November 2018 (UTC)

Voting

Statements with deprecated and preferred rank should be much easier to identify in the Wikidata item pages

Support Edit proposal/discussion

  • Problem: There is hard to distinguisch which statements have preferred and wich deprecated rank. Usually the best ranks are used in queries and in other wiki projects, but these are not easilly to distinguish. On the other side deprecated satements are usually not of big importance, but visualizing them in the same manner like statements with normal and preferred rank complicates the readibility.
  • Who would benefit: The acceptance of wikidata statements in other wiki projects, the wikidata projects itself (editors and users can more easylly distinguish between ranks).
  • Proposed solution: One possible solution would be that in SQID
  • More comments:
  • Phabricator tickets: T87327, T139081, T198907
  • Proposer: Datawiki30 (talk) 20:57, 7 November 2018 (UTC)

Discussion

  • Whilst not taking away from your request, which I think makes good sense, deprecated statements can be made a bit more obvious by adding a reason for deprecation (P2241) qualifier.
The design of the visual distinction would need some care, on the one hand to make the unusual rank more obvious; but on the other hand still being quite subtle, to avoid too much damaging the visual unity and visual flow of the page. For example, Reasonator distinguishes quite strongly between statements of different rank, but I find its very pronounced bold for preferred items (see eg: Glasgow - Population [2]) to be overdone and distracting. Jheald (talk) 15:36, 9 November 2018 (UTC)
  • A pink pastel and a green pastel for deprecated and preferred ranks might be a nice way to meet the intent of this wishlist item. --Izno (talk) 17:53, 9 November 2018 (UTC)
  • I’ve added phab:T198907. In that task you can find CSS snippets to put into your Wikidata common.css which highlight both ranks. —MisterSynergy (talk) 01:33, 17 November 2018 (UTC)

Voting

Ability to filter Watchlist in Wikidata via language

Support Edit proposal/discussion

  • Problem: I have many items on my watchlist in Wikidata and I'm only able to evaluate the quality of edits of labels/descriptions/interwikilinks in German and English. Yet whenever there are changes in another language on the items I watch they show up and clutter my watchlist.
  • Who would benefit: All Wikidata editors who use the watchlist.
  • Proposed solution: Allow users to filter out changes in the watchlist that aren't in the languages in their babel box.
  • More comments:
  • Phabricator tickets: T43686, T141866, T90435
  • Proposer: ChristianKl (talk) 12:25, 3 November 2018 (UTC)

Discussion

  • wikidata:User:Yair rand/DiffLists.js can do this to some extent if you include that script in your wikidata common.js (code: mw.loader.load( '//www.wikidata.org/w/index.php?title=User:Yair_rand/DiffLists.js&action=raw&ctype=text/javascript', 'text/javascript' ); // [[User:Yair rand/DiffLists.js]]). —MisterSynergy (talk) 13:30, 3 November 2018 (UTC)
  • I support this request. The main issue is with added descriptions/aliases of other languages which I don't speak (Side benefit for this request: filtering out recent changes entries => less purges/reparsing?). eranroz (talk) 18:16, 10 November 2018 (UTC)

Voting

Indicate when Wikidata sitelink is to a redirect

Support Edit proposal/discussion

  • Problem: The Wikidata community has now decided that sitelinks to (some) redirects should be allowed. (see RFC;subsequent discussion; 25,000 current uses of Template:Wikidata redirect on en-wiki).
    Where a Wikidata item links to a page that is a redirect on a particular wiki, it would be good if this was indicated on the Wikidata page; and by that wiki's entry in the sidebar interwiki links section of its corresponding Wikipedia pages. (An 'R' on a red circle might be appropriate next to the link, in at least some languages)
  • Who would benefit: Readers, who would know whether to expect the iw link to take them to an article with a matching subject; or whether the link would instead redirect to a related or umbrella topic.
  • Proposed solution: A relatively easy way to achieve this might be to use the "badge" mechanism, as currently used to identify interwikis to good and featured articles.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jheald (talk) 16:22, 9 November 2018 (UTC)

Discussion

  • If I understand well the problem we have a script for this: mw.loader.load( '//www.wikidata.org/w/index.php?title=User:Matěj_Suchánek/checkSitelinks.js&action=raw&ctype=text/javascript' ); It show redirect and disambiguation. --ValterVB (talk) 19:01, 17 November 2018 (UTC)
  • I suggest to indicate links to redirects in the iwl sidebar simply by using italics. This does not consume more space and would be in line with how redirects are rendered if they show up in categories. --(Matthiaspaul) 178.10.50.191 20:56, 17 November 2018 (UTC)
The script add a simple, little icon (Redirect arrow without text (cropped).svg or Disambig.svg) is more clear that the use of italics. --ValterVB (talk) 21:13, 17 November 2018 (UTC)

Voting

Geolocator for wikidata coordinates property

Support Edit proposal/discussion

  • Problem: hard to enter coordinates in wikidata, have to go to external tool and copy and paste
  • Who would benefit: wikidata users
  • Proposed solution: popup map next to every coordinate property, to be able to pin on the map, to provide semi automated entry of geocordinates for that item
  • More comments:
  • Phabricator tickets:
  • Proposer: :JarrahTree (talk) 11:09, 10 November 2018 (UTC)

Discussion

  • I like the idea. This proposal is also related.--Micru (talk) 13:07, 10 November 2018 (UTC)
  • It would be very convenient. I would also like to add that there should be an ability to pick accuracy of coordinates with accuracy options displayed not as "0.0001" but as "+-5 meters" with accuracy also depicted on map as a square. --Tohaomg (talk) 20:56, 10 November 2018 (UTC)
  • +1; additionally I'd prefer DD (Decimal Degrees) format for coordinates or at least a Special:Preferences setting for that. --katpatuka (talk) 12:34, 11 November 2018 (UTC)

Voting

Automatically add inverse properties

Support Edit proposal/discussion

  • Problem: It takes a long time to add inverse statements, father/mother -> child; owner of-> owned by; Spouse/Partner (including qualifiers start time, place of marriage, etc)
  • Who would benefit: Everyone editing
  • Proposed solution: Possibility to automatically add inverse statements, including qualifiers.
  • More comments:
  • Phabricator tickets:
  • Proposer: Germartin1 (talk) 16:43, 9 November 2018 (UTC)

Discussion

  • At the moment we have d:User:Frettie/consistency check add.js, which allows to add inverse properties manually very quickly; of course doing it automatically would be great. --Epìdosis 14:47, 11 November 2018 (UTC)
  • I actually wonder why inverse properties exist in the first place. It seems like they exist so that the inverse can be referenced on other wikis. Perhaps it would be better to make it easy to reference "the inverse" in a sidebar on Wikipedia instead of having to actually duplicate the data in the database. For instance, if there was a way to say that I want the items, where the "father" is this page, it would give me a list of the page's children. That seems like it would be way better than trying to ensure that the inverse statements are correct everywhere. U+1F360 (talk) 23:22, 14 November 2018 (UTC)

Voting

  • Support Support --Tohaomg (talk) 18:22, 16 November 2018 (UTC)
  • Support Support As I added above, I think the reasons why we have inverse properties should be investigated first (as their might be a better technical solution that removes the need for them). But if removing them is impossible, then we should make it faster/easier to add them. U+1F360 (talk) 21:53, 16 November 2018 (UTC)
  • Support Support Consulnico (talk) 00:07, 17 November 2018 (UTC)
  • Support Support Meisam (talk) 00:07, 17 November 2018 (UTC)
  • Support Support Moebeus (talk) 01:06, 17 November 2018 (UTC)
  • Support Support Inverse properties are trivial case of properties which can be derived from other properties. See https://phabricator.wikimedia.org/T167521 for more complicated cases. We should have some mechanism to define such properties. Maybe as "read-only" properties automatically generated if some condition is met. One danger of inverse properties is thay have to be removed in 2 places. One thing we do not want is a property added by bot, so if a person deleted one of them bots re-adds them based on the other one. Jarekt (talk) 05:47, 17 November 2018 (UTC)
  • Support Support Hadrianus (talk) 10:39, 17 November 2018 (UTC)
  • Support Support Frettie (talk) 10:57, 17 November 2018 (UTC)
  • Support Support Libcub (talk) 11:35, 17 November 2018 (UTC)
  • Support Support ديفيد عادل وهبة خليل 2 (talk) 11:44, 17 November 2018 (UTC)
  • Support Support Walter Klosse (talk) 11:56, 17 November 2018 (UTC)
  • Support Support Shisma (talk) 12:29, 17 November 2018 (UTC)
  • Support Support Naseweis520 (talk) 15:19, 17 November 2018 (UTC)
  • Support Support Blue Rasberry (talk) 15:34, 17 November 2018 (UTC)
  • Support Support Make this optional, and only for logged in users. Micru (talk) 16:19, 17 November 2018 (UTC)
  • Support Support Kette~cawiki (talk) 17:40, 17 November 2018 (UTC)
  • Support Support Crazy1880 (talk) 17:55, 17 November 2018 (UTC)
  • Support Support Theklan (talk) 18:20, 17 November 2018 (UTC)
  • Support Support Pichpich (talk) 19:01, 17 November 2018 (UTC)
  • Support Support Shev123 (talk) 19:51, 17 November 2018 (UTC)
  • Support Support also "has part" - "part of" and similar. Perhaps the properties could be "weak ones" - autogenerated, unless someone overrides them? Andree.sk (talk) 19:58, 17 November 2018 (UTC)
  • Support Support Property P190 (twinned administrative body) would be anaother good example Gelli1742 (talk) 20:23, 17 November 2018 (UTC)
  • Support Support JAn Dudík (talk) 20:34, 17 November 2018 (UTC)
  • Support Support Nk (talk) 20:39, 17 November 2018 (UTC)
  • Support Support Metrónomo-Goldwyn-Mayer 21:11, 17 November 2018 (UTC)
  • Support Support Epìdosis 22:52, 17 November 2018 (UTC)
  • Support Support model and implement 1:1, 1:n, n:m relationships navigable in both directions as single entities and all operations (like add & remove) as atomic, not as two inverse properties (which exposes an implementation detail). The names of the relationship's ends still should make sense, like ownes and owned by.. Herzi Pinki (talk) 22:52, 17 November 2018 (UTC)
  • Support Support Nickw25 (talk) 23:18, 17 November 2018 (UTC)
  • Support Support Liuxinyu970226 (talk) 01:27, 18 November 2018 (UTC)
  • Support Support NMaia (talk) 11:01, 18 November 2018 (UTC)
  • Support Support As is is already checked if the reverse is missing, it would "just" need a confirm botton. --Eingangskontrolle (talk) 11:28, 18 November 2018 (UTC)
  • Support Support VIGNERON * discut. 12:38, 18 November 2018 (UTC)
  • Support Support Juandev (talk) 13:07, 18 November 2018 (UTC)
  • Support Support Jeb (talk) 15:51, 18 November 2018 (UTC)
  • Support SupportBeleg Tâl (talk) 16:17, 18 November 2018 (UTC)
  • Support Support Beat Estermann (talk) 16:42, 18 November 2018 (UTC)
  • Support Support — Draceane talkcontrib. 17:26, 18 November 2018 (UTC)
  • Support Support Schwede66 (talk) 17:49, 18 November 2018 (UTC)
  • Support Support Gerd Fahrenhorst (talk) 20:26, 18 November 2018 (UTC)
  • Support Support Hyperik (talk) 20:32, 18 November 2018 (UTC)
  • Support Support Wesalius (talk) 22:04, 18 November 2018 (UTC)
  • Support Support Viswaprabha (talk) 23:33, 18 November 2018 (UTC)
  • Support Support Zeromonk (talk) 09:31, 19 November 2018 (UTC)
  • Support Support katpatuka (talk) 10:45, 19 November 2018 (UTC)
  • Support Support Geraki TL 14:04, 19 November 2018 (UTC)
  • Support Support really this would be super helpful, not having inverse properties makes writing queries sometimes very confusing John Cummings (talk) 15:13, 19 November 2018 (UTC)
  • Support Support Hibm98 (talk) 16:43, 19 November 2018 (UTC)

Navigate Wikidata items through category items

Support Edit proposal/discussion

  • Problem: At the present moment Petscan allows the user to input one or more categories of one single project (e.g. en.wikipedia, it.wikipedia ...) and a depth (e.g. 0, 1, 2 ...) and find all the items containing one sitelink which bellongs to this category or its subcategories. However, the user has to input one by one all the categories regarding the same topic in different projects (e.g. en.wikipedia - Ancient Greece, it.wikipedia - Antica Grecia ...; the most important categories exist in tens of projects!) and cannot easily compare the results for each project.
  • Who would benefit: Wikidata users who try to find and merge duplicates (the user can explore in one single list all the items belonging to the same categories in all the projects); Wikipedia users who want to translate articles regarding a specific topic (the user can see in one single list all the items regarding this topic in all the project)
  • Proposed solution: The main idea is the possibility to explore at the same time all the articles belonging to a category which is common to two or more projects: in my opinion, the best option would be integrating this function into Petscan, but it may also be a new independent tool. The tool should be like this: the user inputs a category item (e.g. d:Q7215882) and a depth (e.g. 0, 1, 2 ...); given these inputs, the tool should give a list of all the items containing at least one sitelink which belongs to a category that is a sitelink of the category item. Possible filters: by type of project (all projects; only Wikipedias; only Wikisources ...); by the date of the articles' creation.
  • More comments:
  • Phabricator tickets:
  • Proposer: Epìdosis 08:50, 4 November 2018 (UTC)

Discussion

Voting

Link labels/aliases of Q-items to lexemes

Support Edit proposal/discussion

  • Problem: There is no easy way to navigate from Q-items to their connected L-items
  • Who would benefit: All wikidata editors, specially those working with lexicographical data.
  • Proposed solution: it would be nice to have a script or gadget that converts the labels/aliases of a Q-item into links to L-items that are connected with "item for this sense (P5137)". So basically what it should do is to see if the text of any of the forms of the linked L-items matches 1-to-1 with any of the label/aliases of the Q-item for that language, and if it does, it should convert the text of the label/alias into a link to the L-item.
  • More comments: Normally there should be only one exact match per label, but there is at least a known exeption: both "gwenn (L30900)" (noun) and "gwenn (L30901)" (adjective) link to "white (Q23444)". For cases like this it would be nice if the additional L-items are linked with a superindex if possible, if not then it is ok to just link one of them for a first version.
  • Phabricator tickets:
  • Proposer: Micru (talk) 10:19, 7 November 2018 (UTC)

Discussion

There is a team with six developers, a engineering manager, a product manager and a liaison devoted to lexicographical data. This proposal is addressed to Tech Team, so on which aspect of your proposal do you think Tech team can help? Noé (talk) 16:36, 17 November 2018 (UTC)

Voting

Sort claims of a property by date

Support Edit proposal/discussion

  • Problem: Currently Wikidata do not sort claims of a property and it could cause terrible mess. Many templates on a lot of Wikipedias load their parameters from Wikidata, so there are thousands of articles where parameters (e.g. awards) aren't in ordinal scale (but they should be). Fixing is very hard or almost impossible, because the only way to do it is deleting and re-adding every claims.
Two examples:
Sergei Movsesian (Q460020) has more than a thousand ELO rating claims, sorting them without any automatic solution would be impossible.
Hermann Kövess von Kövessháza (Q78544): a person has won an award (A, B, C, D, E) year by year and the Wikidata item looks like this:
  • B (2001)
  • C (2002)
  • D (2003)
  • E (2004)
Now, if I want to add A (2000), I have to delete all of them, put 'A' to the first place and then add the others.
  • Who would benefit: Editors of Wikidata, plus readers of Wikipedias which are using templates loading information from Wikidata.
  • More comments:

Discussion

Voting