Community Wishlist Survey 2019/Wikidata
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)
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
- Support Leiem (talk) 05:42, 17 November 2018 (UTC)
- Support Libcub (talk) 11:46, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:50, 17 November 2018 (UTC)
- Support Ita140188 (talk) 13:50, 17 November 2018 (UTC)
- Support Metrónomo-Goldwyn-Mayer 21:13, 17 November 2018 (UTC)
- Support --Vercelas (quæstiones?) 21:18, 17 November 2018 (UTC)
- Support Without Yair rand/DiffLists.js Wikidatas Watchlist would be completely unusable! Please add this functionality! MichaelSchoenitzer (talk) 00:46, 18 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:25, 18 November 2018 (UTC)
- Support Sadads (talk) 18:48, 19 November 2018 (UTC)
- Support Andrewredk (talk) 20:14, 20 November 2018 (UTC)
- Support see also proposed frontend solution (phab:T176515), if we go for backend solution I suggest to revisit phab:T172914 and think about improvements in the entity tracking eranroz (talk) 22:18, 20 November 2018 (UTC)
- Support Joalpe (talk) 22:18, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:00, 21 November 2018 (UTC)
- Support SelfieCity (talk) 19:16, 22 November 2018 (UTC)
- Support Satdeep Gill (talk) 05:47, 23 November 2018 (UTC)
- Support Ederporto (talk) 02:25, 24 November 2018 (UTC)
- Support PMG (talk) 10:20, 26 November 2018 (UTC)
- Support bdijkstra (talk) 10:55, 27 November 2018 (UTC)
- Support Nemo 22:25, 27 November 2018 (UTC)
- Support Schniggendiller (talk) 16:14, 30 November 2018 (UTC)
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:
- Proposer: Jo-Jo Eumerus (talk, contributions) 09:10, 2 November 2018 (UTC)
Discussion
Voting
- Support ديفيد عادل وهبة خليل 2 (talk) 11:44, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:25, 18 November 2018 (UTC)
- Support NMaia (talk) 10:58, 18 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:13, 21 November 2018 (UTC)
- Support As proposer Jo-Jo Eumerus (talk, contributions) 10:11, 25 November 2018 (UTC)
- Neutral A single reference on Wikidata may contain more than one property-value pair and all of them can be added at once. Enumerating all of them (if not all, which one? the first/last one?) in the edit summary may be undesired. Matěj Suchánek (talk) 10:33, 25 November 2018 (UTC)
- Support Olea (talk) 21:32, 29 November 2018 (UTC)
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.
- Proposed solution: Automatic sorting for some properties like spouse (P26) or award received (P166) etc. with using start time (P580), end time (P582), point in time (P585) and others.
- More comments:
- Phabricator tickets: T173432
- Proposer: Bencemac (talk) 13:47, 31 October 2018 (UTC)
Discussion
- It would be great and will simplify reading of some properties having multiple values. I’ve written a script specifically for software version identifier (P348) but a Wikibase-integrated solution would be better. I just added some ideas in the Phabricator task, basically to allow editors to define themselves the order instead of hardcoding it in Wikibase. ~ Seb35 [^_^] 12:17, 4 November 2018 (UTC)
- After dates, sorting by xsd:integer(series ordinal (P1545)) then raw series ordinal (P1545) would also be useful to add to any default ordering. Jheald (talk) 19:33, 5 November 2018 (UTC)
- Not all properties should be sorted by date. Some, like cast member (P161) should be ordered by series ordinal (P1545) as seen on Star Wars: Episode VII – The Force Awakens (Q6074). So perhaps it would be best to allow property values to be sorted by a specific qualifier? This could be added as a statement on the property itself. U+1F360 (talk) 01:20, 8 November 2018 (UTC)
Voting
- Support --Tohaomg (talk) 18:25, 16 November 2018 (UTC)
- Support Libcub (talk) 11:36, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:48, 17 November 2018 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:53, 17 November 2018 (UTC)
- Support JAn Dudík (talk) 20:34, 17 November 2018 (UTC)
- Support Metrónomo-Goldwyn-Mayer 21:10, 17 November 2018 (UTC)
- Support Epìdosis 22:51, 17 November 2018 (UTC)
- Support Nickw25 (talk) 23:14, 17 November 2018 (UTC)
- Support MichaelSchoenitzer (talk) 00:47, 18 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:27, 18 November 2018 (UTC)
- Support Psychoslave (talk) 04:21, 18 November 2018 (UTC)
- Support Szalax (talk) 08:57, 18 November 2018 (UTC)
- Support Zabia (talk) 10:15, 18 November 2018 (UTC)
- Support Richard Nevell (talk) 10:37, 18 November 2018 (UTC)
- Support Sebastian Wallroth (talk) 10:40, 18 November 2018 (UTC)
- Support Eingangskontrolle (talk) 11:35, 18 November 2018 (UTC)
- Support Wolbo (talk) 12:24, 18 November 2018 (UTC)
- Support Beat Estermann (talk) 16:35, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:25, 18 November 2018 (UTC)
- Support Schwede66 (talk) 17:46, 18 November 2018 (UTC)
- Support Dvorapa (talk) 19:19, 18 November 2018 (UTC)
- Support Needed for sorting “significant events”. PKM (talk) 00:58, 19 November 2018 (UTC)
- Support Sabas88 (talk) 09:10, 19 November 2018 (UTC)
- Support Zeromonk (talk) 09:29, 19 November 2018 (UTC)
- Support katpatuka (talk) 10:42, 19 November 2018 (UTC)
- Support Marsupium (talk) 11:06, 19 November 2018 (UTC)
- Support Dhx1 (talk) 12:59, 19 November 2018 (UTC)
- Support Hibm98 (talk) 16:39, 19 November 2018 (UTC)
- Support Sadads (talk) 18:46, 19 November 2018 (UTC)
- Support I would like to see this, but take into account that some claims should be sorted by other qualifieres (see my note above). U+1F360 (talk) 21:04, 19 November 2018 (UTC)
- Support Vulphere 12:57, 20 November 2018 (UTC)
- Support sorting claims by qualifier per U+1F360 Wikisaurus (talk) 14:26, 20 November 2018 (UTC)
- Support CAPTAIN RAJU(T) 22:57, 20 November 2018 (UTC)
- Support As the proposer. Bencemac (talk) 08:12, 21 November 2018 (UTC)
- Support Ayack (talk) 09:22, 21 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:12, 21 November 2018 (UTC)
- Support Pppery (talk) 00:40, 22 November 2018 (UTC)
- Support Nvrandow (talk) 20:08, 23 November 2018 (UTC)
- Support James F. (talk) 22:44, 23 November 2018 (UTC)
- Support Sannita - not just another it.wiki sysop 00:35, 24 November 2018 (UTC)
- Support Yes, we should be able to specify different ordering for different properties: by date qualifier, alphabetically, or by some other qualifiers. Jarekt (talk) 05:18, 25 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 03:02, 26 November 2018 (UTC)
- Support PMG (talk) 10:26, 26 November 2018 (UTC)
- Support Olea (talk) 21:33, 29 November 2018 (UTC)
- Support NicoScribe (talk) 11:27, 30 November 2018 (UTC)
- Support Movses (talk) 14:12, 30 November 2018 (UTC)
- Support NickK (talk) 15:55, 30 November 2018 (UTC)
- Support Schniggendiller (talk) 16:01, 30 November 2018 (UTC)
- Support Yiyi (talk) 16:04, 30 November 2018 (UTC)
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)
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)
- @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)
- phab:T206426 is only for multilingual wiki, not general wikipedia projects. C933103 (talk) 15:26, 13 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 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 C933103 (talk) 07:04, 17 November 2018 (UTC)
- Support Jc86035 (talk) 10:47, 17 November 2018 (UTC)
- Support Libcub (talk) 11:38, 17 November 2018 (UTC)
- Support Walter Klosse (talk) 13:28, 17 November 2018 (UTC)
- Support JAn Dudík (talk) 20:33, 17 November 2018 (UTC)
- Support Zabia (talk) 10:15, 18 November 2018 (UTC)
- Partial 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 Per Beat Estermann — Draceane talkcontrib. 17:21, 18 November 2018 (UTC)
- Support Dvorapa (talk) 19:23, 18 November 2018 (UTC)
- Support Per Beat Estermann Pharos (talk) 05:43, 19 November 2018 (UTC)
- Support Mend My Way 23:51, 19 November 2018 (UTC)
- Support Toto256 (talk) 06:39, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:11, 21 November 2018 (UTC)
- Support with "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)" in mind. Topper13009 (talk) 20:34, 21 November 2018 (UTC)
- Support GPSLeo (talk) 20:19, 22 November 2018 (UTC)
- Support BugWarp (talk) 14:58, 23 November 2018 (UTC)
- Support NaBUru38 (talk) 18:30, 23 November 2018 (UTC)
- Support Nvrandow (talk) 20:18, 23 November 2018 (UTC)
- Support Dreamy Jazz (talk) 13:27, 26 November 2018 (UTC)
- Support Olea (talk) 21:28, 29 November 2018 (UTC)
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)
Discussion
Voting
- Support Libcub (talk) 11:43, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:49, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:23, 18 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:10, 21 November 2018 (UTC)
- Support Vulphere 01:20, 22 November 2018 (UTC)
- Support I would have found it useful to have sometimes Alexmar983 (talk) 01:33, 27 November 2018 (UTC)
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)
Discussion
- 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)
Voting
- Support Libcub (talk) 11:41, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:46, 17 November 2018 (UTC)
- 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 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 Liuxinyu970226 (talk) 01:22, 18 November 2018 (UTC)
- Support Krokofant (talk) 05:49, 19 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:09, 21 November 2018 (UTC)
- Oppose Agree with User:Jc86035 that although this would be good to have, it's not the role of this discussion to request it. MartinPoulter (talk) 12:15, 22 November 2018 (UTC)
- Support Sebastian.Dietrich (talk) 18:46, 26 November 2018 (UTC)
- Support Olea (talk) 21:27, 29 November 2018 (UTC)
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)
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
- Support Libcub (talk) 11:36, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:43, 17 November 2018 (UTC)
- Support but why should that be a gadget? Shisma (talk) 12:26, 17 November 2018 (UTC)
- Support Micru (talk) 16:20, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 02:16, 18 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:07, 21 November 2018 (UTC)
- Support GAllegre (talk) 13:58, 27 November 2018 (UTC)
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.
- Proposer: Jo-Jo Eumerus (talk, contributions) 09:11, 2 November 2018 (UTC)
Discussion
Voting
- Support Galobtter (talk) 18:51, 16 November 2018 (UTC)
- Support Consulnico (talk) 00:08, 17 November 2018 (UTC)
- Support Cbyd (talk) 10:40, 17 November 2018 (UTC)
- Support Libcub (talk) 11:37, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:49, 17 November 2018 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:56, 17 November 2018 (UTC)
- Support Ita140188 (talk) 13:52, 17 November 2018 (UTC)
- Support Jc86035 (talk) 18:27, 17 November 2018 (UTC)
- Support AllyD (talk) 18:38, 17 November 2018 (UTC)
- Support Pichpich (talk) 18:57, 17 November 2018 (UTC)
- Support Winged Blades of Godric (talk) 19:50, 17 November 2018 (UTC)
- Support Kpjas (talk) 22:33, 17 November 2018 (UTC)
- Support ARR8 (talk) 23:04, 17 November 2018 (UTC)
- Support MichaelSchoenitzer (talk) 00:48, 18 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:25, 18 November 2018 (UTC)
- Support Jklamo (talk) 03:43, 18 November 2018 (UTC)
- Support ChristianKl ❪✉❫ 09:19, 18 November 2018 (UTC)
- Support Wolbo (talk) 12:29, 18 November 2018 (UTC)
- Support Beat Estermann (talk) 16:39, 18 November 2018 (UTC)
- Support Dhx1 (talk) 12:57, 19 November 2018 (UTC)
- Support –Ejs-80 12:32, 20 November 2018 (UTC)
- Support Vulphere 12:54, 20 November 2018 (UTC)
- Support Gareth (talk) 13:18, 20 November 2018 (UTC)
- Support — Draceane talkcontrib. 19:05, 20 November 2018 (UTC)
- Support Tris T7 (talk) 02:31, 21 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:12, 21 November 2018 (UTC)
- Support Nvrandow (talk) 20:11, 23 November 2018 (UTC)
- Support Matěj Suchánek (talk) 09:43, 24 November 2018 (UTC)
- Support Pamputt (talk) 08:18, 25 November 2018 (UTC)
- Support As proposer Jo-Jo Eumerus (talk, contributions) 10:11, 25 November 2018 (UTC)
- Support AnBuKu (talk) 14:23, 25 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 03:00, 26 November 2018 (UTC)
- Support PMG (talk) 10:23, 26 November 2018 (UTC)
- Support Linguistical (talk) 14:02, 27 November 2018 (UTC)
- Support Oh please make this happen! NessieVL (talk) 15:52, 29 November 2018 (UTC)
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
- ↑ 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
Discussion from before the start of voting. Jc86035 (talk) 11:39, 17 November 2018 (UTC) |
---|
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)
Define Quality of external source and double checkI think Open Free Knowledge most important component is having references to external trusted sources. I therefore would like to see
- 09:56, 30 October 2018 (UTC)
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)
|
- Support Minihaa (talk) 17:22, 28 November 2018 (UTC)
- Support Olea (talk) 21:30, 29 November 2018 (UTC)
Voting
- Support Jc86035 (talk) 05:16, 17 November 2018 (UTC)
- Support Libcub (talk) 11:45, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:49, 17 November 2018 (UTC)
- Support Giovanni Alfredo Garciliano Diaz (talk) 17:16, 17 November 2018 (UTC)
- Support Thibdx (talk) 17:58, 17 November 2018 (UTC)
- Support PamD (talk) 18:51, 17 November 2018 (UTC)
- Support Metrónomo-Goldwyn-Mayer 21:12, 17 November 2018 (UTC)
- Support Capankajsmilyo (talk) 00:07, 18 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:23, 18 November 2018 (UTC)
- Support Sounds like a basic requirement to backup Wikipedia mission on neutrality and trustability. Also, still in the vain of trustability by traceability, one should also be able to get the license of the sources, to let reuser of large portion of Wikidata that they are not unwillingly using Wikidata as a license laundering canal. See Address concerns about perceived legal uncertainty of Wikidata for this later point. Psychoslave (talk) 04:12, 18 November 2018 (UTC)
- Support NMaia (talk) 10:57, 18 November 2018 (UTC)
- Support Hydriz (talk) 12:35, 18 November 2018 (UTC)
- Support Beat Estermann (talk) 16:38, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:22, 18 November 2018 (UTC)
- Support Hadi (talk) 20:58, 18 November 2018 (UTC)
- Support Sabas88 (talk) 09:20, 19 November 2018 (UTC)
- Support Vulphere 12:56, 20 November 2018 (UTC)
- Support Ecritures (talk) 20:09, 20 November 2018 (UTC)
- Support Hispalois (talk) 22:43, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:00, 21 November 2018 (UTC)
- Support Spacearcangel (talk) 19:03, 22 November 2018 (UTC)
- Support Nikkimaria (talk) 22:28, 25 November 2018 (UTC)
- Support Why not letting the creation of Wikidata items for sources, for example: a news article or a book, so these can be linked to the statements as sources backing up them. Hienafant (talk) 19:45, 22 November 2018 (UTC)
- Support Sannita - not just another it.wiki sysop 00:36, 24 November 2018 (UTC)
- Support Redalert2fan (talk) 12:47, 24 November 2018 (UTC)
- Support Ranjithsiji (talk) 22:30, 25 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 02:58, 26 November 2018 (UTC)
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)
Discussion
Voting
- Support Libcub (talk) 11:46, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:50, 17 November 2018 (UTC)
- Support Metrónomo-Goldwyn-Mayer 21:03, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:27, 18 November 2018 (UTC)
- Support Jklamo (talk) 03:42, 18 November 2018 (UTC)
- Support Szalax (talk) 08:57, 18 November 2018 (UTC)
- Support NMaia (talk) 10:57, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:22, 18 November 2018 (UTC)
- Support Sabas88 (talk) 09:10, 19 November 2018 (UTC)
- Support Dhx1 (talk) 12:50, 19 November 2018 (UTC)
- Support Lostinlodos (talk) 01:20, 20 November 2018 (UTC)
- Support Vulphere 13:00, 20 November 2018 (UTC)
- Support Gareth (talk) 13:08, 20 November 2018 (UTC)
- Support Laboramus (talk) 07:17, 21 November 2018 (UTC)
- Support β16 - (talk) 10:04, 21 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:08, 21 November 2018 (UTC)
- Support Pppery (talk) 00:40, 22 November 2018 (UTC)
- Support BugWarp (talk) 14:57, 23 November 2018 (UTC)
- Support Sannita - not just another it.wiki sysop 00:35, 24 November 2018 (UTC)
- Support Matěj Suchánek (talk) 09:43, 24 November 2018 (UTC)
- Support Ranjithsiji (talk) 22:28, 25 November 2018 (UTC)
- Support Tantusar (talk) 00:45, 26 November 2018 (UTC)
- Support Csigabi (talk) 18:18, 28 November 2018 (UTC)
- Support Wargo (talk) 19:45, 29 November 2018 (UTC)
- Support Olea (talk) 21:26, 29 November 2018 (UTC)
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)
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)
- 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
- Support ديفيد عادل وهبة خليل 2 (talk) 11:47, 17 November 2018 (UTC)
- Support MichaelSchoenitzer (talk) 00:48, 18 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:25, 18 November 2018 (UTC)
- Support Richard Nevell (talk) 10:45, 18 November 2018 (UTC)
- Support Sabas88 (talk) 09:21, 19 November 2018 (UTC)
- Support Dhx1 (talk) 12:47, 19 November 2018 (UTC)
- Support Sadads (talk) 18:47, 19 November 2018 (UTC)
- Support Mounir Touzri (talk) 00:23, 20 November 2018 (UTC)
- Support 朝彦 | Asahiko (talk) 07:55, 20 November 2018 (UTC)
- Support Vulphere 12:55, 20 November 2018 (UTC)
- Support Laboramus (talk) 07:16, 21 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:11, 21 November 2018 (UTC)
- Support Ayack (talk) 16:32, 21 November 2018 (UTC)
- Support Sannita - not just another it.wiki sysop 00:36, 24 November 2018 (UTC)
- Support Matěj Suchánek (talk) 09:43, 24 November 2018 (UTC)
- Support PMG (talk) 10:25, 26 November 2018 (UTC)
- Support GAllegre (talk) 13:59, 27 November 2018 (UTC)
- Support YFdyh000 (talk) 20:02, 27 November 2018 (UTC)
- Support --Papuass (talk) 14:34, 30 November 2018 (UTC)
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)
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)
- Support italics. Paine Ellsworth put'r there 17:32, 20 November 2018 (UTC)
- The script add a simple, little icon ( or ) is more clear that the use of italics. --ValterVB (talk) 21:13, 17 November 2018 (UTC)
Voting
- Support sounds really helpful Moebeus (talk) 01:14, 17 November 2018 (UTC)
- Support Hiàn (talk) 04:07, 17 November 2018 (UTC)
- Support Leiem (talk) 05:41, 17 November 2018 (UTC)
- Support as a step to getting links to appropriate redirects unblocked Certes (talk) 10:36, 17 November 2018 (UTC)
- Support Jc86035 (talk) 10:46, 17 November 2018 (UTC)
- Support Libcub (talk) 11:48, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:48, 17 November 2018 (UTC)
- Support Zoranzoki21 (talk) 14:26, 17 November 2018 (UTC)
- Support Nouill (talk) 15:13, 17 November 2018 (UTC)
- Support Yes to an automatic "redirect badge". Micru (talk) 16:18, 17 November 2018 (UTC)
- Support Hadn't even thought of the badge approach. One way or another this would be very useful. ArthurPSmith (talk) 16:47, 17 November 2018 (UTC)
- Support Giovanni Alfredo Garciliano Diaz (talk) 17:20, 17 November 2018 (UTC)
- Support JAn Dudík (talk) 20:34, 17 November 2018 (UTC)
- Support --(Matthiaspaul) 178.10.50.191 20:56, 17 November 2018 (UTC)
- Support Metrónomo-Goldwyn-Mayer 21:04, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:26, 18 November 2018 (UTC)
- Support Jklamo (talk) 03:46, 18 November 2018 (UTC)
- Support ChristianKl ❪✉❫ 09:20, 18 November 2018 (UTC)
- Support NMaia (talk) 10:59, 18 November 2018 (UTC)
- Support Sebastian Wallroth (talk) 13:07, 18 November 2018 (UTC)
- Support Pharos (talk) 05:46, 19 November 2018 (UTC)
- Support katpatuka (talk) 10:53, 19 November 2018 (UTC)
- Support Dhx1 (talk) 12:52, 19 November 2018 (UTC)
- Support Toto256 (talk) 06:41, 20 November 2018 (UTC)
- Support Shmurak (talk) 08:33, 20 November 2018 (UTC)
- Support Vulphere 13:00, 20 November 2018 (UTC)
- Support, esp. if shown in italics format. Paine Ellsworth put'r there 17:32, 20 November 2018 (UTC)
- Support Rachel Helps (BYU) (talk) 19:01, 20 November 2018 (UTC)
- Support Joalpe (talk) 22:18, 20 November 2018 (UTC)
- Support CAPTAIN RAJU(T) 22:57, 20 November 2018 (UTC)
- Support Tris T7 (talk) 02:39, 21 November 2018 (UTC)
- Support BMK (talk) 11:35, 21 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:09, 21 November 2018 (UTC)
- Support Gce (talk) 17:31, 21 November 2018 (UTC)
- Support --Moroboshi (talk) 13:46, 26 November 2018 (UTC)
- Support Everytime I stumble on a redirect I think about this idea Alexmar983 (talk) 01:34, 27 November 2018 (UTC)
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)
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)
- @Germartin1: How would this handle qualifiers and references, and statements with the same value but different qualifiers (for e.g. adjacent stations, offices held)? I like this proposal (and added my support vote) but I think these are things that would need to be addressed in the implementation. Jc86035 (1) (talk) 08:11, 20 November 2018 (UTC)
- I found task T209559 which seems to cover what I mentioned above. --U+1F360 (talk) 04:22, 23 November 2018 (UTC)
- @Germartin1: I use Property:P1545 as qualifier in Property:P26. And i don't want to copy the Property:P1545 value! Manu1400 (talk) 04:15, 25 November 2018 (UTC)
Voting
- Support --Tohaomg (talk) 18:22, 16 November 2018 (UTC)
- 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 Consulnico (talk) 00:07, 17 November 2018 (UTC)
- Support Meisam (talk) 00:07, 17 November 2018 (UTC)
- Support Moebeus (talk) 01:06, 17 November 2018 (UTC)
- 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 Hadrianus (talk) 10:39, 17 November 2018 (UTC)
- Support Frettie (talk) 10:57, 17 November 2018 (UTC)
- Support Libcub (talk) 11:35, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:44, 17 November 2018 (UTC)
- Support Walter Klosse (talk) 11:56, 17 November 2018 (UTC)
- Support Shisma (talk) 12:29, 17 November 2018 (UTC)
- Support Naseweis520 (talk) 15:19, 17 November 2018 (UTC)
- Support Blue Rasberry (talk) 15:34, 17 November 2018 (UTC)
- Support Make this optional, and only for logged in users. Micru (talk) 16:19, 17 November 2018 (UTC)
- Support Kette~cawiki (talk) 17:40, 17 November 2018 (UTC)
- Support Crazy1880 (talk) 17:55, 17 November 2018 (UTC)
- Support Theklan (talk) 18:20, 17 November 2018 (UTC)
- Support Pichpich (talk) 19:01, 17 November 2018 (UTC)
- Support Shev123 (talk) 19:51, 17 November 2018 (UTC)
- 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 Property P190 (twinned administrative body) would be anaother good example Gelli1742 (talk) 20:23, 17 November 2018 (UTC)
- Support JAn Dudík (talk) 20:34, 17 November 2018 (UTC)
- Support Nk (talk) 20:39, 17 November 2018 (UTC)
- Support Metrónomo-Goldwyn-Mayer 21:11, 17 November 2018 (UTC)
- Support Epìdosis 22:52, 17 November 2018 (UTC)
- 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 Nickw25 (talk) 23:18, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:27, 18 November 2018 (UTC)
- Support NMaia (talk) 11:01, 18 November 2018 (UTC)
- 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 VIGNERON * discut. 12:38, 18 November 2018 (UTC)
- Support Juandev (talk) 13:07, 18 November 2018 (UTC)
- Support Jeb (talk) 15:51, 18 November 2018 (UTC)
- Support —Beleg Tâl (talk) 16:17, 18 November 2018 (UTC)
- Support Beat Estermann (talk) 16:42, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:26, 18 November 2018 (UTC)
- Support Schwede66 (talk) 17:49, 18 November 2018 (UTC)
- Support Gerd Fahrenhorst (talk) 20:26, 18 November 2018 (UTC)
- Support Hyperik (talk) 20:32, 18 November 2018 (UTC)
- Support Wesalius (talk) 22:04, 18 November 2018 (UTC)
- Support Viswaprabha (talk) 23:33, 18 November 2018 (UTC)
- Support Zeromonk (talk) 09:31, 19 November 2018 (UTC)
- Support katpatuka (talk) 10:45, 19 November 2018 (UTC)
- Support Geraki TL 14:04, 19 November 2018 (UTC)
- 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 Hibm98 (talk) 16:43, 19 November 2018 (UTC)
- Support Jmmuguerza (talk) 23:35, 19 November 2018 (UTC)
- Support Jc86035 (1) (talk) 07:42, 20 November 2018 (UTC)
- Support 朝彦 | Asahiko (talk) 07:54, 20 November 2018 (UTC)
- Support Gareth (talk) 13:13, 20 November 2018 (UTC)
- Support Vadimzer (talk) 17:26, 20 November 2018 (UTC)
- Support Rachel Helps (BYU) (talk) 19:00, 20 November 2018 (UTC)
- Support Joalpe (talk) 22:19, 20 November 2018 (UTC)
- Support CAPTAIN RAJU(T) 22:58, 20 November 2018 (UTC)
- Support Omotecho (talk) 03:35, 21 November 2018 (UTC)
- Support Vulphere 05:13, 21 November 2018 (UTC)
- Support At least checking and easily creating the other end for symmetrical properties (spouse, etc.) would be great. Note we'd also need to be careful with qualifiers. References should be carried over too. Laboramus (talk) 07:14, 21 November 2018 (UTC)
- Support Acer11 (talk) 08:01, 21 November 2018 (UTC)
- Support Ayack (talk) 09:15, 21 November 2018 (UTC)
- Support β16 - (talk) 10:12, 21 November 2018 (UTC)
- Support Geogast (talk) 13:36, 21 November 2018 (UTC)
- Support Novak Watchmen (talk) 15:10, 21 November 2018 (UTC)
- Support Hienafant (talk) 19:47, 22 November 2018 (UTC)
- Support TomT0m (talk) 19:53, 22 November 2018 (UTC) Although something more ambitious like inferred statement would be really cool. I guess it’s a step towards that goal :) @Markus Krötzsch: TomT0m (talk) 19:53, 22 November 2018 (UTC)
- Support I agree Poslovitch (talk) 20:34, 22 November 2018 (UTC)
- Support Thibdx (talk) 20:47, 22 November 2018 (UTC)
- Support Wostr (talk) 20:50, 22 November 2018 (UTC)
- Support. Useful. Nomen ad hoc (talk) 21:51, 22 November 2018 (UTC).
- Strong oppose I'm sorry but this is NOT a good idea for several reasons: (1) We have several properties that are stated as "inverses" but are not really - for example "part of" vs "has part"; for concrete entities they are pretty close to exact inverses, but in more abstract cases not so much, and there are things like "has parts of the class" that are better ways to handle the relation. (2) Do we want every entity in the universe listed under the "universe" item, since everything is "part of" the universe? This is a very general issue: many relations that are invertible are "one to many" type, where there would be only one statement on thousands of items on one side, with thousands of statements on the one item on the other side. Sometimes for many-to-many relations they are close to "one-to-many" in some contexts and "many-to-one" in others - that is, sometimes one side of the relation and sometimes the other side would be unreasonable to reify as statements on items. (3) We would need to be very careful with vandalism of properties: if a vandal stated that some other property was an "inverse of" a widely used property like for example P31 (instance of), and the system automatically created millions of such statements, we would have a terrible mess to clean up. (4) There is already a javascript gadget to do this at least as far as the UI goes - 'User:Pasleim/derivedstatements.js' - maybe that needs some improvement or cleanup, but an approach like that is the only way I could see this being useful, i.e. actually generating the inverse statements in real time based on current data, rather than inserting inverse statements into items in a more permanent manner. ArthurPSmith (talk) 16:39, 23 November 2018 (UTC)
- Support Sahaquiel9102 (talk) 17:34, 23 November 2018 (UTC)
- Support Nvrandow (talk) 20:04, 23 November 2018 (UTC)
- Oppose (with the understanding that oppose votes are not counted here) per Arthur in full. I think this is useful for properties where the likelihood of introducing unnecessary bloat to items is very low, but I am against using this functionality with properties that have a strong likelihood for bloat (such as "part of", "has part", and most recently "owner of" and "owned by"). Mahir256 (talk) 21:07, 23 November 2018 (UTC)
- Strong oppose per Mahir256 and Arthur.Winged Blades of Godric (talk) 06:21, 24 November 2018 (UTC)
- Neutral Manu1400 (talk) 04:12, 25 November 2018 (UTC)
- Support Ranjithsiji (talk) 22:27, 25 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 02:59, 26 November 2018 (UTC)
- Support Sebastian.Dietrich (talk) 18:47, 26 November 2018 (UTC)
- Support YFdyh000 (talk) 20:00, 27 November 2018 (UTC)
- Support Mhmrodrigues (talk) 20:17, 28 November 2018 (UTC)
- Support Only as optional, not as mandatory. It can be either per property (e.g. father/mother -> child is automatic, part of is not) or as an option (Preferences, pop-up etc.) — NickK (talk) 15:32, 30 November 2018 (UTC)
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:
- Phabricator tickets: phab:T116762
- Proposer: ChristianKl (talk) 19:54, 1 November 2018 (UTC)
Discussion
Voting
- Support HHill (talk) 21:36, 16 November 2018 (UTC)
- Support Hiàn (talk) 04:06, 17 November 2018 (UTC)
- Support Jo-Jo Eumerus (talk, contributions) 10:24, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:46, 17 November 2018 (UTC)
- Support Shisma (talk) 12:27, 17 November 2018 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:55, 17 November 2018 (UTC)
- Support Giovanni Alfredo Garciliano Diaz (talk) 17:19, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 01:25, 18 November 2018 (UTC)
- Support Perhaps have the label as well as the item ID? Richard Nevell (talk) 10:39, 18 November 2018 (UTC)
- Support NMaia (talk) 10:55, 18 November 2018 (UTC)
- Support Ainali (talk) 12:51, 18 November 2018 (UTC)
- Support Beat Estermann (talk) 16:50, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:21, 18 November 2018 (UTC)
- Support Viswaprabha (talk) 23:31, 18 November 2018 (UTC)
- Support Zeromonk (talk) 09:23, 19 November 2018 (UTC)
- Support katpatuka (talk) 10:48, 19 November 2018 (UTC)
- Support Dhx1 (talk) 12:58, 19 November 2018 (UTC)
- Support Geert Van Pamel (WMBE) (talk) 13:54, 19 November 2018 (UTC)
- Support Sadads (talk) 18:46, 19 November 2018 (UTC)
- Support PiotrekD (talk) 21:47, 19 November 2018 (UTC)
- Support Vulphere 13:00, 20 November 2018 (UTC)
- Support Gareth (talk) 13:27, 20 November 2018 (UTC)
- Support Laboramus (talk) 07:10, 21 November 2018 (UTC)
- Support Novak Watchmen (talk) 14:59, 21 November 2018 (UTC)
- Support Nvrandow (talk) 20:13, 23 November 2018 (UTC)
- Support Possibly in emails as well. Matěj Suchánek (talk) 09:41, 24 November 2018 (UTC)
- Support Redalert2fan (talk) 12:45, 24 November 2018 (UTC)
- Support AnBuKu (talk) 14:25, 25 November 2018 (UTC)
- Support Ranjithsiji (talk) 22:29, 25 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 03:02, 26 November 2018 (UTC)
- Support Gideoraielgave (talk) 17:18, 26 November 2018 (UTC)
- Support Schniggendiller (talk) 16:09, 30 November 2018 (UTC)
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)
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)
- @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)
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)
Notifying everyone who supportedVoting
- Support HHill (talk) 21:33, 16 November 2018 (UTC)
- Support Jc86035 (talk) 04:47, 17 November 2018 (UTC)
- Support Mahir256 (talk) 06:07, 17 November 2018 (UTC)
- Support Acamicamacaraca (talk) 08:06, 17 November 2018 (UTC)
- Support Libcub (talk) 11:40, 17 November 2018 (UTC)
- Support ديفيد عادل وهبة خليل 2 (talk) 11:47, 17 November 2018 (UTC)
- Support Wostr (talk) 15:16, 17 November 2018 (UTC)
- Support Mike Peel (talk) 15:16, 17 November 2018 (UTC)
- Support M11rtinb (talk) 15:18, 17 November 2018 (UTC)
- Support Ederporto (talk) 15:41, 17 November 2018 (UTC)
- Support Very needed! Micru (talk) 16:17, 17 November 2018 (UTC)
- Support This would be potentially very helpful in handling vandalism. ArthurPSmith (talk) 16:45, 17 November 2018 (UTC)