Community Wishlist Survey 2019/Wikidata

From Meta, a Wikimedia project coordination wiki
Wikidata
19 proposals, 231 contributors, 552 support votes
The survey has closed. Thanks for your participation :)



Ability to filter Watchlist in Wikidata via language

  • 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)[reply]

Discussion

Voting

Display reference in edit summary when a reference is added

  • 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

Sort claims of a property by date

  • 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

Solution to the ‟Bonnie and Clyde” problem

  • 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)[reply]

Discussion

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. ChristianKl18:38, 14 November 2018 (UTC)[reply]

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)[reply]

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)[reply]

Voting

Navigate Wikidata items through category items

  • 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)[reply]

Discussion

Voting

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

  • 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)[reply]

Discussion

  • 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)[reply]

Voting

Link labels/aliases of Q-items to lexemes

  • 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 exception: 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)[reply]

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)[reply]

Voting

Expand automatic edit summaries

  • 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

Improvements to the reliability of Wikidata

  • 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)[reply]

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)[reply]
Discussion from before the start of voting. Jc86035 (talk) 11:39, 17 November 2018 (UTC)[reply]

One issue that I hit recently is outdate Wikipedia imports. For instance, a (wrong) set of coordinates was imported from de.wp. In the mean time, the data was corrected on Wikipedia, but not Wikidata. A lot of additional work can be done on coordinates, such as supporting areas, which in turn allows checks such as "is this coordinate within the area indicated by the P31 of the item?"--Strainu (talk) 21:55, 29 October 2018 (UTC)[reply]

@Strainu: I agree; I've added a sentence about this to the proposal. Jc86035 (talk) 05:53, 30 October 2018 (UTC)[reply]
  • One possibility would be to add a button "doubtful" to the right of the "edit" button. Then others could query the doubtful statements (possibly using Wikidata Query) and fix the problems by deleting or editing the bad quality or wrong statements. Geert Van Pamel (WMBE) (talk) 10:47, 4 November 2018 (UTC)[reply]
    @Geertivp: I think that sounds like a good idea; such a feature could be used to add preset tags like in Wikipedia articles (e.g. citation needed, needs update, doubtful/dubious), possibly by making the script add qualifiers to statements. I have proposed a property for this information, since one does not yet exist. Jc86035 (talk) 11:16, 4 November 2018 (UTC)[reply]
    See also phabricator:T139583 --Lydia Pintscher (WMDE) (talk) 13:51, 9 November 2018 (UTC)[reply]
  • There is a way in Lua to ensure that only sourced properties are displayed in templates. That could be a first move for critical pages. Another idea could be to convert URL listed as sources into special items that could be reviewed to status on the source quality. This could be partially automated using the source base URL. Pubmed is reliable. CNN is quite reliable. The Onion is fake. -- Thibdx (talk) 00:08, 5 November 2018 (UTC)[reply]

Define Quality of external source and double check

I think Open Free Knowledge most important component is having references to external trusted sources. I therefore would like to see

  • in the Wikipedia infobox
    • that the reader easy can see
      • that a fact is based on an external source
      • the quality of source used - we need to find a way to describe quality of a source and our experience using it
      • that we have confirmed that this fact is the same as an external fact compare Listeria list that runs daily comparing Wikidata with Nobelprize.org link see example diff
    • that we also visualize in the Wikipedia infobox a mismatch with an external source found in Wikidata

- 09:56, 30 October 2018 (UTC)

@Salgo60: Added a sentence and a note to the proposal. The English Wikipedia's WikidataIB Lua module is able to filter statements based on whether or not they have a source which is not to a WMF project, but I don't think it's able to display sources from Wikidata. Jc86035 (talk) 13:21, 30 October 2018 (UTC)[reply]
I think the quality of a source might be difficult to categorize, although perhaps one could filter out sources which are blacklisted by the English Wikipedia for being unusable. Jc86035 (talk) 13:37, 30 October 2018 (UTC)[reply]
Thanks If you listen to the vision of en:Tim Berners-Lee then in an en:linked data world then I as a reader should be able to select what sources I trust... I feel Trust is very important and we need to think about how Wikipedia explains to the reader the quality of used sources. One vision could also be that I as an reader of Wikipedia should be able to see what facts in the article I read is based on sources I trust - Salgo60 (talk) 13:44, 30 October 2018 (UTC)[reply]
  • Basically your solution to vandalism is to prevent Wikipedia editors without existing Wikidata edits from removing vandalism that might show up on Wikipedia for critical fields. That sounds to me like a bad plan. ChristianKl (talk) 18:03, 2 November 2018 (UTC)[reply]
    @ChristianKl: Not necessarily (although that specificially would probably not be a good idea). Obviously what exactly to protect would be decided by Wikidata admins. You might
    • prevent a class of users from editing a group of pages;
    • prevent a class of users from editing specific parts of a group of pages;
    • prevent a class of users from adding statements without references on a group of pages;
    • prevent a class of users from adding statements without references on specific parts of a group of pages;
    • prevent a class of users from editing existing data for a group of pages;
    • prevent a class of users from editing some existing data for a group of pages.
    The latter two would probably be quite difficult to implement properly without preventing some registered users from reverting vandalism and without preventing some users from editing the data that they just added, although perhaps they could be limited to the scope of statements with existing references which have URLs or which cite another item.
    I think some of these would also be particularly useful for items about scientific articles, since usually after import they shouldn't need to be edited manually (and edits are likely to come from Special:Random). Jc86035 (talk) 05:19, 3 November 2018 (UTC)[reply]
I would forbid that it could be put "imported from Wikimedia project (P143)", because we are not a primary source and can not serve as a reference in certain affirmations. --Vanbasten 23 (talk) 11:11, 4 November 2018 (UTC)[reply]

Jc86035 Hello. Thanks for submitting a proposal for the wishlist survey. This proposal is very broad and proposes a number of different solutions. I'd encourage you to make the problem statement more focused on specific issues (like Ability to easily import references) that are individually actionable. Otherwise it will be very hard for us to focus our work on what's important. Thank you. -- NKohli (WMF) (talk) 23:40, 5 November 2018 (UTC)[reply]

@NKohli (WMF): Would it be sufficient for me to order the Phabricator tickets (once I create them) from most important to least? I think they're all important, although some of them would certainly have a bigger impact than others. Jc86035 (talk) 14:08, 6 November 2018 (UTC)[reply]
@Jc86035: Just writing down what you think are the steps to solve this in order of importance would be fine. Phabricator tickets would be nice but aren't necessary. I can't say we will be able to do everything but having the proposed solution in order of importance according to you would be helpful. I see Geert Van Pamel and Lydia suggested a solution above. You could also incorporate that in the proposal if you think it's a good idea. Thank you. -- NKohli (WMF) (talk) 22:49, 9 November 2018 (UTC)[reply]
@Jc86035: Thanks for trimming this down. I think the remaining phab tickets are more on the scale of what Community Tech could work on. Ryan Kaldari (WMF) (talk) 21:04, 15 November 2018 (UTC)[reply]
@Jc86035: I think taking out the crossed-out sentences will make this a lot more readable. Thank you. -- NKohli (WMF) (talk) 21:42, 15 November 2018 (UTC)[reply]

Voting

More fine-grained diffs for Wikidata

  • 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)[reply]

Discussion

Voting

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

  • 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)[reply]

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 deprecated rank (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)[reply]

Voting

Indicate when Wikidata sitelink is to a redirect

  • 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)[reply]

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)[reply]
The script add a simple, little icon ( or ) is more clear that the use of italics. --ValterVB (talk) 21:13, 17 November 2018 (UTC)[reply]

Voting

Automatically add inverse properties

  • 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)[reply]

Discussion

Voting

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

  • Problem:
    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:

Discussion

Voting

Partial and multi-item protection for Wikidata items

  • 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)[reply]

Discussion

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)[reply]

Voting

Freely editable input mask

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • What is wrong with d:WD:QuickStatements? --Izno (talk) 01:44, 6 November 2018 (UTC)[reply]
    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)[reply]
  • 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)[reply]

Voting

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

  • 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)[reply]

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)[reply]

Voting

Geolocator for wikidata coordinates property

  • 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)[reply]

Discussion

Voting

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

  • 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)[reply]

Discussion

Originally this proposal was broader in scope, so many of the comments discuss separate issues. Jc86035 (talk) 11:51, 17 November 2018 (UTC)[reply]
Discussion from before the start of voting. Jc86035 (talk) 11:51, 17 November 2018 (UTC)[reply]
  • Please add other Phabricator tickets if you think they are relevant to this request (although not necessarily those which are children of tasks already linked). Thanks, Jc86035 (talk) 08:38, 30 October 2018 (UTC)[reply]
  • Addon: Some properties like P150 (contains administrative territorial entity) seem to slow down the opening or scrolling of a page. Add a 'collapsable' (Hide/Show) possibility for properties which list many items --katpatuka (talk) 06:17, 4 November 2018 (UTC)[reply]
@Katpatuka: Do you want to improve the page load time (i.e. something like making statements load "lazily" after the initial page load) or do you want to allow properties to be collapsed? Jc86035 (talk) 06:49, 4 November 2018 (UTC)[reply]
@Jc86035: Both may be possible... I'm not a coder but I notice that I have to wait 3-5 seconds until the whole page has opened fully - so some sort of profiling would be good. For example if I click the edit link (connecting to wikidata:Special:SetLabelDescriptionAliases) too early only wikidata:File:Set_label,_description_and_aliases.png shows up without the rest of the page (using Firefox 52.9.0). --katpatuka (talk) 09:16, 4 November 2018 (UTC)[reply]
@Katpatuka: I've added three tickets (the last three) to the list; do you think something is missing? Jc86035 (talk) 09:27, 4 November 2018 (UTC)[reply]
@Jc86035: Should be ok then, thanks ;) --katpatuka (talk) 09:56, 4 November 2018 (UTC)[reply]
Partial (lazy) loading, or collapsing Statements might lead to a higher risk of duplicate data. I would never recommend it. For the same reason there is no "Statement Add" button at the top of the page; only at the bottom, so users need to scrol down and read existing Statements. I encounter the problem of duplicate data already now on pages with a lot of Statements. Rather I would choose for a logical/structured sequence of properties + alphabetical sorting (e.g. in Aliases or multiple alma mater, professions, functions, contains, etc.). We should always see all statements for one item. To prevent duplicate data I would implement an online constraint checking with an error message before saving the data. But some pseudo-duplicate statements are always possible: e.g. multiple official web sites, multiple VIAF codes, etc. Speeding up page load should always be a point of attention; but even more important is completeness and referential integrity improving the overall data quality. Geert Van Pamel (WMBE) (talk) 14:12, 4 November 2018 (UTC)[reply]
Principle of software engineering: first make it work, then only make it fast, efficient, and nice. Geert Van Pamel (WMBE) (talk) 08:46, 5 November 2018 (UTC)[reply]
  • It could be really useful to have a "Wikidata usability initiative" similar to Wikipedia's one. There is more room that what we can imagine for usability improvements on Wikidata. This would greatly empower the contributors. I know that this type of project need a full time team of UX specialists. It needs a specific funding. --Thibdx (talk) 00:14, 5 November 2018 (UTC)[reply]

Unfortunately, our team will not be able to work on this proposal because it wants to address too many things that it should have really been their own proposals. Even if we didn't work on any other proposal, we couldn't possibly finish this in a year. MaxSem (WMF) (talk) 00:38, 15 November 2018 (UTC)[reply]

@MaxSem (WMF): I've only linked to eleven tickets, excluding the Epic ones (which I was not expecting to actually be worked on, and it would obviously be impossible to create all the datatypes Wikidata will ever need). If I were to remove the tickets that are not bold-formatted and the "no tickets yet" points, or even just the Epic ones, would it be small enough? Jc86035 (talk) 06:03, 15 November 2018 (UTC)[reply]
@Jc86035:, we discussed this and consensus was that if you kept only the date related issues, this proposal would be fine. MaxSem (WMF) (talk) 19:08, 15 November 2018 (UTC)[reply]
@Jc86035:, you still have time to amend. MaxSem (WMF) (talk) 07:59, 16 November 2018 (UTC)[reply]
@MaxSem (WMF): By "date-related issues", are you referring to the time datatype issues (i.e. adding seconds precision and time zones), the date display issues, or both? I have amended the proposal so that only date-related issues are listed, so it should already be a bit smaller than some other proposals which haven't been archived. Jc86035 (talk) 10:22, 16 November 2018 (UTC)[reply]
@MaxSem (WMF): Since voting opens in less than five hours and I won't be staying up all night, I will be moving this proposal back myself. If it is still too much then I think it would be better to remove the parts of the proposal which pertain to adding hour/second/minute precision than to archive the proposal outright. Jc86035 (talk) 15:10, 16 November 2018 (UTC)[reply]
Eh some of those tickets are actually related so that it's possible that there's a synergy effect in reducing workload that they might not be as much as they seems. C933103 (talk) 06:16, 15 November 2018 (UTC)[reply]
  • 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)[reply]

Voting