Community Wishlist Survey 2016/Categories/Wikidata
Thank you for participating! The 2016 Community Wishlist Survey has concluded.
Checkout the 2017 survey at Community Wishlist Survey 2017! |
Primary Sources: When a claim from the tool gets approved, the page shouldn't get reloaded
- Problem: Currently the page reloads every time a claim from the Primary Source tool get's approved or disapproved.
- Who would benefit: All users of the Primary Source tool, because editing is easier. All downstream users of Wikidata for domains where the Primary Source tool has data, because more data would be added.
- Proposed solution: Don't reload the page when claims get approved or disapproved but simply communicate the information in the background to the server and show the claim on the client side as a normal Wikidata statement.
- Phabricator tickets: phab:T148179
- Proposer: ChristianKl (talk) 17:29, 15 November 2016 (UTC)
- Translations: none yet
Community discussion
- none
Voting – Primary Sources: Don't reload when a claim from the tool gets approved
- Support And I could see this for other edits as well, Sadads (talk) 15:10, 28 November 2016 (UTC)
- Support --Micru (talk) 16:08, 28 November 2016 (UTC)
- Support --Izno (talk) 01:25, 29 November 2016 (UTC)
- Support ChristianKl (talk) 16:08, 29 November 2016 (UTC)
- Support -- Mushroom (talk) 22:08, 29 November 2016 (UTC)
- Support --Jklamo (talk) 15:04, 30 November 2016 (UTC)
- Support --Geraki TL 06:41, 2 December 2016 (UTC)
- Support--Runner1928 (talk) 02:43, 5 December 2016 (UTC)
- Support --Epìdosis 20:09, 5 December 2016 (UTC)
- Support--Nikosguard (talk) 09:24, 6 December 2016 (UTC)
- Support - DPdH (talk) 21:19, 11 December 2016 (UTC)
Query OpenStreetMap database for Wikidata links for each item
- Problem: See d:WD:PFD#P402 (permalink as of 13 November) and discussion at T145284. Links from OSM database (which is easily queried) to Wikidata are much more stable than in the other direction.
- Who would benefit: Wikidata and OpenStreetMap editors, plus Wikidata readers who might not otherwise know that this geographical data exists.
- Proposed solution: On every WD item, make a query to the OSM database (there are several different APIs by which this could be done) to see if there are any links to it.
- Phabricator tickets: None yet.
- Proposer: Jc86035 (talk) 10:03, 13 November 2016 (UTC)
- Translations: none yet
Community discussion
- Pinging Yurik. Jc86035 (talk) 10:03, 13 November 2016 (UTC)
- I believe you Jc86035 has the same concerns on this subject as Susannaanas, I see why this could possible be a issue as the existing solution without a identifier in Wikidata decreases the discover-ability. I'm afraid a new database(which would simply be a extract from OSM) is not a solution to this issue. Abbe98 (talk) 21:11, 13 November 2016 (UTC)
- Yes, I have changed my vote on this topic to focus on the OSM database instead of the Wikidata ID 402, but make sure the geographic data will be as easily queryable as if it was a native Wikidata ID. I would not want to impose the 402 ID database solution to be the selected one to solve the issue. --Susanna Ånäs (Susannaanas) (talk) 07:14, 14 November 2016 (UTC)
- this sounds like a bot request not something for wikimedia developers? ArthurPSmith (talk) 15:00, 14 November 2016 (UTC)
- @ArthurPSmith: No, not a bot request (automatic display of info based on querying their API), although it would be perfectly fine if it were implemented that way and the Wikidata database was updated whenever the OSM database had a change (and vice versa). Jc86035 (talk) 11:12, 16 November 2016 (UTC)
- @Jc86035: I don't believe wikidata or any WMF project should be dependent in its UI on some outside project, if that's what you're implying. However, this could be implemented as an optional gadget that does the work via javascript - again probably not something for WMF developers to do. ArthurPSmith (talk) 14:48, 16 November 2016 (UTC)
- Here is a UserScript which adds a link to the item's corresponding OpenStreetMap element, it will add a link whenever there is a wikidata tag referencing the item's URI over at OpenStreetMap. Abbe98 (talk) 20:00, 18 November 2016 (UTC)
- WMF is already mantaining a OSM Wikidata extract (the geoshapes service of Kartotherian), so it could build on this to satisfy this proposal. I strongly suggest against mantaining the Wikidata property to link to OSM because OpenStreetMap IDs are not stable (they can change for a given object when someone makes for example a split of a way). --Sabas88 (talk) 10:48, 3 December 2016 (UTC)
Voting – Query OpenStreetMap database for Wikidata links for each item
Show only items that are allowed given the constraints of property when the user searches for them
- Problem: When a user adds a new statement and searches for the proper item to link he's shown many items that aren't allowed by the constraints set on the property.
This means it takes more effort to select the right one.
- Who would benefit: All Wikidata editors. It would also make it easier to become a Wikidata editor
- Proposed solution: Only items that are allowed given the constraints that are set via statements for the property that's used should be shown in the text based search.
It should still be possible to select items that violate the constrains by entering the ID of the item.
- Phabricator tickets:
- Proposer: ChristianKl (talk) 21:50, 10 November 2016 (UTC)
- Translations: none yet
ChristianKl (talk) 21:50, 10 November 2016 (UTC)
Community discussion
- Good idea! JnRouvignac (talk) 22:54, 11 November 2016 (UTC)
- Much needed! An obvious first step would be to filter out disambiguation pages. Syced (talk) 15:40, 14 November 2016 (UTC)
- This functionality is offered by the suggestions. However, it can be improved and it also doesn't work for qualifiers. To make the suggestor work for qualifiers currently, you must save the statement and then open the qualifier which will narrow the number of possible choices in the drop-down considerably. Jane023 (talk) 15:48, 14 November 2016 (UTC)
- @Jane023:What exactly do you mean with the suggestions? Those items that are offered without typing anything? ChristianKl (talk) 13:23, 15 November 2016 (UTC)
- For example, if I use P217 for "inventory number", I can save that statement. This property is suggested correctly to me after I add P31 instance of "painting". That is correct behavior of the suggestor functionality. The problem with qualifiers is that for this statement, I would prefer to have it qualified with the collection, but the suggestor does not suggest P195 for "collection" unless I first save the P217 statement and open it again to add the qualifier. It should be possible for the suggestor to suggest the P195 qualifier as it is probably the most common qualifier for the P217 statement. Jane023 (talk) 10:46, 30 November 2016 (UTC)
- @Jane023:What exactly do you mean with the suggestions? Those items that are offered without typing anything? ChristianKl (talk) 13:23, 15 November 2016 (UTC)
- Something like that seems useful.--Alexmar983 (talk) 05:31, 16 November 2016 (UTC)
- Instead of restricting only to allowed items, I would rather have them appearing first in the choices. --Melderick (talk) 21:27, 20 November 2016 (UTC)
- I'm not really convinced that our constraint definitions can't be improved and that the universe should be limited by them, but it would help if it was more likely that useful values come first. In any case, I think the situation has much improved some time ago. At some point, one couldn't even get to useful items .. --Jura1 (talk) 23:09, 20 November 2016 (UTC)
- I agree with Jura1 here. We should spend time on improving our constraint system and related tools and not move away from one of the fundamental concepts of Wikidata. --Lydia Pintscher (WMDE) (talk) 08:30, 23 November 2016 (UTC)
- I'm not proposing creating a hard limit of the universe. It would still be possible to enter items that violate constraints by entering the items ID. In most cases it would just require a conscious choice to violate the constraint. A user would have to specifically search for the item and enter the ID.
- The effect of this proposal is that *items should follow the constraints* not that *items must follow the constraints*. When constraints are violated, there should the a conscious decision whether this is simply an exception (in that case it's okay to go through the extra effort of searching the ID) or whether the constraint definition should be changed. ::ChristianKl (talk) 23:49, 27 November 2016 (UTC)
- If we would really think that everything goes as far as property usage and property can be used in ways that are very different from the way they were proposed the current proposal system doesn't make sense. This would encourage people to use the property the way it was proposed or alternatively advocate changing the property. ChristianKl (talk) 16:11, 29 November 2016 (UTC)
- In case the implemented feature is about moving items that match constraints to the top I would also a visual marker for those statements that violate constraints. ChristianKl (talk) 11:10, 1 December 2016 (UTC)
Voting – Show only items that are allowed given the constraints of property
- Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)
- Support--Gareth (talk) 12:03, 28 November 2016 (UTC)
- Support ChristianKl (talk) 16:09, 29 November 2016 (UTC)
- Oppose if this is a hard constraint; Support if the matching items are moved to the top of the list but others are also available ArthurPSmith (talk) 17:48, 29 November 2016 (UTC)
- Support anything to improve suggestions is welcome. Jane023 (talk) 10:48, 30 November 2016 (UTC)
- per ArthurPSmith, Support to prioritize items that are allowed given the constraints, Oppose to hide not allowed completely. --Jklamo (talk) 15:09, 30 November 2016 (UTC)
- Oppose per Arthur. --AmaryllisGardener talk 19:03, 1 December 2016 (UTC)
- as per ArthurPSmith. Oppose if this is a hard constraint; Support if the matching items are moved to the top of the list but others are also available. --FocalPoint (talk) 19:41, 1 December 2016 (UTC)
- Support Libcub (talk) 03:42, 2 December 2016 (UTC)
- Support matching items are moved to the top of the list but others are also available. Oppose to hide others. --Geraki TL 06:42, 2 December 2016 (UTC)
- Support --Entbert (talk) 15:12, 2 December 2016 (UTC)
- Support -- T.seppelt (talk) 16:04, 4 December 2016 (UTC)
- Support-- as others suggested, only to prioritize suggestions by which items are optimal and push to the bottom of suggestions (and maybe mark) those items which violate constraints Runner1928 (talk) 02:45, 5 December 2016 (UTC)
- Support with ArthurPSmith's caveat. --Waldir (talk) 12:10, 10 December 2016 (UTC)
- Support --NaBUru38 (talk)
- Support --Chrumps (talk) 03:18, 11 December 2016 (UTC)
- Support -- Gelli1742 (talk) 11:11, 11 December 2016 (UTC)
- Support - DPdH (talk) 21:19, 11 December 2016 (UTC)
- Support I see a problem if the target item doesn't have (enough) statements; so per ArthurPSmith. --KuboF (talk) 21:57, 12 December 2016 (UTC)
- Support by giving priority to more relevant items (but not completely banning irrelevant). It is a bit annoying to fix people born in a bot named Algeria or a hotel named Ukraine — NickK (talk) 23:21, 12 December 2016 (UTC)
- Support Obviously. --Yann (talk) 23:51, 12 December 2016 (UTC)
Statistics of use of Wikidata's data
- Problem: At this moment it is difficult, and probably even quite impossible, to measure the quantitative effect and impact of the work that we, volunteers, do on Wikidata. Where is our data used, re-used? How often is the data viewed - both on Wikimedia projects and externally? We can measure pageviews of Wikipedia articles, to a certain extent views of media files, but we can't measure views and (Wikimedia- or externally originated) pulls and uses of data on Wikidata yet.
- Who would benefit: Everyone in our community probably, especially the Wikidata community, as this would make the impact of our work much more visible, and would also allow us to see where there is still room for improvement. It would be extremely useful for external partners as well. I have worked with several Flemish GLAMs on an import of their collections to Wikidata and their first wish is to see how often their collections are viewed and re-used from Wikidata.
- Proposed solution: Initiate a project to start measuring the actual use and re-use of data on Wikidata. I can imagine this would be measured by item at least.
- More comments: We discussed this in a Wikidata+GLAM session at Wikimania 2016. Some basic notes from that discussion can be found here in this etherpad (scroll down to the bottom in the pad). When this proposal is endorsed by enough others, I (Spinster (talk)) am very willing to structure this further.
- Phabricator tickets: phab:T138697 (still empty, more info in etherpad mentioned above)
- Proposer: Spinster (talk) 20:16, 15 November 2016 (UTC)
- Translations: none yet
Community discussion
- This is an aspect to fix. Something easy like a link "what uses this" instead of "what links here" would be nice to have. On commons cross-wiki use of a file is easy to get, it should be as easy also for wikidata information.--Alexmar983 (talk) 05:12, 16 November 2016 (UTC)
- Unlike its countrparts, Wikidata is used mostly dynamically. Often by apps outside of Wikimedia, which our privacy policy probably forbids us to disclose. So, a good way to show statistics could be "This item has been read 70 times in the last 24 hours". Syced (talk) 06:00, 16 November 2016 (UTC)
- wait. Are we discussing of a in-wiki reuse or a general reuse? I don't think the proposal was to monitor the second type of reuse, that would be clearly impossible... I think it's about knowing how many templates on local platform uses wikidata information of an item and where, basically.--Alexmar983 (talk) 08:15, 16 November 2016 (UTC)
- It is clearly stated in the description: "both on Wikimedia projects and externally". Cheers! Syced (talk) 09:12, 17 November 2016 (UTC)
- Yes, definitely also external use. I expect we're smart enough to disclose some information about that (numbers, generic categories of types of web services re-using the content...) without violating privacy policies. Spinster (talk) 18:51, 17 November 2016 (UTC)
- I really want this kind of data too but the issue isn't that we have the data and do not share it. We don't actually have the data. Anyone can download for example the database dump and use the data without us having any way of knowing this. There is a research project that was trying to make at least some basic guessing and heuristics about it but it isn't even really started yet. --Lydia Pintscher (WMDE) (talk) 14:11, 18 November 2016 (UTC)
- I am surprised the two aspects were united in a single proposal, there are quite different from a wikimedian point of view. I guess I skipped it because I don't even understand how the second request could be possible. You can get some general summary of views and downloads, I guess, but that better be a separate request. And in any case, spending energy to guess it somehow before a easy interface for monitoring cross-wiki use seems excessive at the moment, the first step should be the "crosswiki" reuse. Instead of having people discussing about something that is needed for "wiki management" we end up discussing mainly about the second aspect, that looks like a dead end at the moment.--Alexmar983 (talk) 08:46, 19 November 2016 (UTC)
- Yes developers can download the whole database and use it locally (just like people can read Wikipedia on a DVD or via the Kiwix apps), but most apps query the live Wikidata dynamically, so counting queries at query.wikidata.org would provide good-enough statistics. Syced (talk) 07:42, 21 November 2016 (UTC)
- I really want this kind of data too but the issue isn't that we have the data and do not share it. We don't actually have the data. Anyone can download for example the database dump and use the data without us having any way of knowing this. There is a research project that was trying to make at least some basic guessing and heuristics about it but it isn't even really started yet. --Lydia Pintscher (WMDE) (talk) 14:11, 18 November 2016 (UTC)
- Yes, definitely also external use. I expect we're smart enough to disclose some information about that (numbers, generic categories of types of web services re-using the content...) without violating privacy policies. Spinster (talk) 18:51, 17 November 2016 (UTC)
- It is clearly stated in the description: "both on Wikimedia projects and externally". Cheers! Syced (talk) 09:12, 17 November 2016 (UTC)
- wait. Are we discussing of a in-wiki reuse or a general reuse? I don't think the proposal was to monitor the second type of reuse, that would be clearly impossible... I think it's about knowing how many templates on local platform uses wikidata information of an item and where, basically.--Alexmar983 (talk) 08:15, 16 November 2016 (UTC)
- @Spinster: Do you want this proposal to focus on interwiki transclusions of Wikidata items or API/external requests for item data? or both? Ryan Kaldari (WMF) (talk) 00:08, 23 November 2016 (UTC)
- Both. They can be split in separate proposals if that makes things clearer. Spinster (talk) 17:02, 23 November 2016 (UTC)
Voting – Statistics of use of Wikidata's data
- Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)
- Support--Gareth (talk) 12:05, 28 November 2016 (UTC)
- Support as proposer. Spinster (talk) 15:37, 29 November 2016 (UTC)
- Support --Mikey641 (talk) 18:26, 29 November 2016 (UTC)
- Support Jane023 (talk) 10:38, 30 November 2016 (UTC)
- Support Yes for better statistics of use for items but also for properties (for example d:Template:ExternalUse should be updated automatically).--Jklamo (talk) 15:17, 30 November 2016 (UTC)
- Support Pamputt (talk) 07:34, 1 December 2016 (UTC)
- Support --Beat Estermann (talk) 09:19, 1 December 2016 (UTC)
- Support Jsamwrites (talk) 18:39, 1 December 2016 (UTC)
- Support --AmaryllisGardener talk 19:03, 1 December 2016 (UTC)
- Support --FocalPoint (talk) 20:49, 1 December 2016 (UTC)
- Support Mike Peel (talk) 22:27, 1 December 2016 (UTC)
- Support SamanthaNguyen (talk) 22:57, 1 December 2016 (UTC)
- Support --WikedKentaur (talk) 23:20, 1 December 2016 (UTC)
- Weak Support This needs to be done in a way that respects the individual's privacy. NMaia (talk) 00:41, 2 December 2016 (UTC)
- Support Libcub (talk) 03:43, 2 December 2016 (UTC)
- Support --Jordi G (talk) 09:05, 2 December 2016 (UTC)
- Support Draceane (talk) 11:00, 2 December 2016 (UTC)
- Support —Jc86035 (talk) 11:22, 2 December 2016 (UTC)
- Support--Adert (talk) 22:44, 2 December 2016 (UTC)
- Support--Pauljmackay (talk) 11:12, 3 December 2016 (UTC)
- Support--Runner1928 (talk) 02:38, 5 December 2016 (UTC)
- Support --Epìdosis 20:10, 5 December 2016 (UTC)
- Support--Nikosguard (talk) 09:21, 6 December 2016 (UTC)
- Support Richard Nevell (WMUK) (talk) 11:15, 6 December 2016 (UTC)
- Support Jianhui67 talk★contribs 11:28, 7 December 2016 (UTC)
- Support In OpenStreetMap they have a statistic tool, called Taginfo. Perhaps this can give some inspirations what is possible. This tool is also integrated in there wiki. --Kolossos (talk) 12:48, 11 December 2016 (UTC)
- Support--David1010 (talk) 20:46, 11 December 2016 (UTC)
- Support - Can't manage what's not measured. DPdH (talk) 21:20, 11 December 2016 (UTC)
- Support--Alexmar983 (talk) 03:50, 12 December 2016 (UTC)
- Support--Mikheil Talk 21:29, 12 December 2016 (UTC)
- Support more statistics — NickK (talk) 23:21, 12 December 2016 (UTC)
Support for Incubator projects
- Problem: Currently it is not possible in Wikidata to add sitelinks to pages that belong to language versions which are still in Incubator (or OldWikisource or BetaWikiversity). This means that editors of these test-projects cannot profit from interwiki links provided by Wikidata and also not from the other data stored on Wikidata.
- Who would benefit: Users who contribute to test-projects on Incubator (OldWS, BetaWV), wanting to start a new language version of one of our projects
- Proposed solution: All language codes permissible for wikimedia projects (ie generally ISO 639-1 and -3) should be available for choosing in the sitelinks sections of Wikidata. When a code is entered of which there is no subdomain (of Wikipedia, Wikivoyage, etc.) yet, the target page should be searched on Incubator. (e.g. Wikipedia sitelinks, code liv, page name X => Search for incubator:Wp/liv/X and allow addition of the link if that page exists). [taken from the bug which I filed]
- Phabricator tickets: bug T54971
- Proposer: MF-W 00:39, 12 November 2016 (UTC)
- Translations: none yet
Community discussion
- Yes, this is a frequently requested feature which has been "in the queue" for too long already, as far as I am concerned. I would really appreciate implementation. --Vogone (talk) 00:42, 12 November 2016 (UTC)
- This would be useful. – Ajraddatz (talk) 19:43, 12 November 2016 (UTC)
- @Lydia Pintscher (WMDE): Is there any reason these are currently excluded? Ryan Kaldari (WMF) (talk) 23:42, 22 November 2016 (UTC)
- They are excluded because many languages are combined in one wiki. For each item on Wikidata we can only link to one article on a wiki. --Lydia Pintscher (WMDE) (talk) 08:11, 23 November 2016 (UTC)
- Fully agreed. NMaia (talk) 00:39, 21 November 2016 (UTC)
- Given that incubator is experimental, I think storage should be done locally, not on Wikidata. --Jura1 (talk) 10:04, 21 November 2016 (UTC)
- Given that incubator aims to provide the exact same user experience as any project with an own domain, integration to Wikidata is pretty crucial to its success. --Vogone (talk) 00:28, 26 November 2016 (UTC)
Voting – Support for Incubator projects
- Support --MF-W 14:20, 28 November 2016 (UTC)
- Support --Vogone (talk) 14:22, 28 November 2016 (UTC)
- Support --Steinsplitter (talk) 15:05, 28 November 2016 (UTC)
- Support --Wolverène 15:18, 28 November 2016 (UTC)
- Support --StevenJ81 (talk) 15:23, 28 November 2016 (UTC)
- Support --Micru (talk) 16:09, 28 November 2016 (UTC)
- Support --Base (talk) 16:16, 28 November 2016 (UTC)
- Support --GeekEmad (talk) 18:44, 28 November 2016 (UTC)
(was support) --Ibrahim khashrowdi (talk) 18:52, 28 November 2016 (UTC)- For the record, User:Ibrahim khashrowdi has stated on Incubator that he now opposes, in that he is concerned it will create a disincentive for the Language Committee to move projects out of Incubator. StevenJ81 (talk) 17:02, 29 November 2016 (UTC)
- Which, also for the record, is complete nonsense, as LangCom (rightly) doesn't care about the usability of Incubator. I say this as a LangCom member. --MF-W 03:21, 1 December 2016 (UTC)
- For the record, User:Ibrahim khashrowdi has stated on Incubator that he now opposes, in that he is concerned it will create a disincentive for the Language Committee to move projects out of Incubator. StevenJ81 (talk) 17:02, 29 November 2016 (UTC)
- Support JAn Dudík (talk) 22:21, 28 November 2016 (UTC)
- Support --Siri111 (talk) 23:04, 28 November 2016 (UTC)
- Support --Yair rand (talk) 07:02, 29 November 2016 (UTC)
- Support --Lsanabria (talk) 15:15, 29 November 2016 (UTC)
- Support SamanthaNguyen (talk) 22:57, 1 December 2016 (UTC)
- Support NMaia (talk) 00:39, 2 December 2016 (UTC)
- Support -Mh7kJ (talk) 01:37, 2 December 2016 (UTC)
- Support Libcub (talk) 03:44, 2 December 2016 (UTC)
- Support Jmvkrecords ⚜ (Intra talk) 10:37, 2 December 2016 (UTC).
- Support - Nikki (talk) 18:20, 2 December 2016 (UTC)
- Support This will be very helpful for instances like voy:fi:, which just got imported with thousands of interwiki links which need to be removed as well as a sidebar which links to language editions of Wikipedia. —Justin (koavf)❤T☮C☺M☯ 19:45, 2 December 2016 (UTC)
- Support --Framawiki (talk) 20:52, 2 December 2016 (UTC)
- Support – Ajraddatz (talk) 23:08, 2 December 2016 (UTC)
- Support. Matiia (talk) 23:13, 2 December 2016 (UTC)
- Support KPFC 💬 23:49, 2 December 2016 (UTC)
- Support the wub "?!" 13:32, 4 December 2016 (UTC)
- Support --SDKmac (talk) 13:45, 4 December 2016 (UTC)
- Support --XXnickiXx (talk) 13:51, 4 December 2016 (UTC)
- Support --Metrophil (talk) 13:52, 4 December 2016 (UTC)
- Support --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (talk) 13:54, 4 December 2016 (UTC)
- Support --Kenny McFly (talk) 13:57, 4 December 2016 (UTC)
- Support --By erdo can • TLK 17:01, 4 December 2016 (UTC)
- Support -- Freddy2001 talk 18:46, 4 December 2016 (UTC)
- Support --DCB (talk) 22:15, 4 December 2016 (UTC)
- Support --Rschen7754 04:44, 5 December 2016 (UTC)
- Support --Epìdosis 20:11, 5 December 2016 (UTC)
- Support Would be a very nice feature that would further lower the difference between regular wikis and Incubator test wikis. As long as it implemented properly, i.e. each test wiki on Incubator is treated as a regular project (being able to add the language link xyz which goes to Wx/xyz/Page on Incubator). SPQRobin (talk) 22:39, 5 December 2016 (UTC)
- Support --HakanIST (talk) 06:38, 6 December 2016 (UTC)
- Support --Liuxinyu970226 (talk) 11:17, 6 December 2016 (UTC)
- Support Pabouk (talk) 13:13, 6 December 2016 (UTC)
- Support Jianhui67 talk★contribs 11:29, 7 December 2016 (UTC)
- Support yes — regards, Revi 06:27, 9 December 2016 (UTC)
- Support --Kusurija (talk) 20:05, 9 December 2016 (UTC)
- Support --DangSunM (talk) 01:46, 10 December 2016 (UTC)
- Support —DerHexer (Talk) 22:58, 10 December 2016 (UTC)
- Support --Wnme 20:35, 11 December 2016 (UTC)
- Support--David1010 (talk) 20:47, 11 December 2016 (UTC)
- Support-- Save the Babies.--Stemoc 02:21, 12 December 2016 (UTC)
- Support--Shanmugamp7 (talk) 02:22, 12 December 2016 (UTC)
- Support. RadiX∞ 02:39, 12 December 2016 (UTC)
- Support Gives more recognition to developing wikis. Ebe123 (Communication | Activity report) 14:55, 12 December 2016 (UTC)
- Support - Useful. Smile4ever (talk) 18:49, 12 December 2016 (UTC)
- Support--Mikheil Talk 21:32, 12 December 2016 (UTC)
- Support --DerMaxdorfer (talk) 22:02, 12 December 2016 (UTC)
- Support In Incbator we are now using methods like "In this space sometime will be information". The possibility to use Wikidata's data would help a lot. --KuboF (talk) 22:05, 12 December 2016 (UTC)
- Support — NickK (talk) 23:22, 12 December 2016 (UTC)
Take care of disambiguation items
- Problem: A sizeable part of Wikidata items are merely about disambiguations. Much of their maintenance could be automatize.
- Who would benefit: Wikidata contributors finding them in other fields
- Proposed solution: Steps are outlined in the infobox "Points to cover" on the right side at d:Wikidata:Bot_requests#Take_care_of_disambiguation_items. Copy below (without the lists and queries included there).
Points to cover |
---|
|
- Phabricator tickets: phab:T139912
- Proposer: Jura1 (talk) 20:30, 20 November 2016 (UTC)
- Translations: none yet
Community discussion
- Yes it should be. Now that we have wikidata, it would be nice to have some automatic disambiguation page. One aspect is how to include the articles that don't exist yet, as it is impossible to tell to a bot if it is a problem of relevance in one wiki, or they haven't been created yet. But if a wiki is very practical, a simple "show as a red link items that exist in at least n wiki" is IMHO a decent compromise if it removes hours of editing. Many wiki will accept it.--Alexmar983 (talk) 11:45, 21 November 2016 (UTC)
- Sure, I guess it could be expanded. With the above, I had in mind mainly the Wikidata side. There are now 1 million such items and they tend to get mixed-up with actual content. --Jura1 (talk) 21:01, 22 November 2016 (UTC)
- @Jura1: Hi, I think this is a duplicate of the more detailed proposal at .../Bots and gadgets#Import Wikidata text for disambiguation pages. If you agree, please can you merge any extra details, into that proposal, and remove this section? (So that people don't have to vote on the same thing twice). If you disagree, please could you clarify your proposal, with more details and examples from the linked page, so that people voting next week can easily understand the idea without having to read that large discussion? Much thanks. Quiddity (WMF) (talk) 02:14, 23 November 2016 (UTC)
- This proposals is about 1,000,000 Wikidata items like d:Q4826629. The other proposal seems to be about pages such as en:Automation_(disambiguation). I think ideally, we'd do both, but they can be done independently. Communities benefiting from them aren't the same either. Obviously, doing the Wikidata side first might be an improved basis for Wikipedia. --Jura1 (talk) 06:58, 23 November 2016 (UTC)
- We can do better with the Wikidata items, like so d:Q4373037. Jane023 (talk) 12:07, 30 November 2016 (UTC)
- Jane23: If it's something you think that could be automatized, you might want to describe how at d:Wikidata:Bot_requests#Take_care_of_disambiguation_items.--Jura1 (talk) 10:03, 10 December 2016 (UTC)
- We can do better with the Wikidata items, like so d:Q4373037. Jane023 (talk) 12:07, 30 November 2016 (UTC)
- This proposals is about 1,000,000 Wikidata items like d:Q4826629. The other proposal seems to be about pages such as en:Automation_(disambiguation). I think ideally, we'd do both, but they can be done independently. Communities benefiting from them aren't the same either. Obviously, doing the Wikidata side first might be an improved basis for Wikipedia. --Jura1 (talk) 06:58, 23 November 2016 (UTC)
Voting – Take care of disambiguation items
- Support --YMS (talk) 16:25, 29 November 2016 (UTC)
- Support --ValterVB (talk) 18:02, 29 November 2016 (UTC)
- Support this sounds helpful - however is there anything on here that actually requires any development, or just getting the community to help fix these things (with some bots)? ArthurPSmith (talk) 18:48, 29 November 2016 (UTC)
- Support we could put disambiguation pages on steroids. Jane023 (talk) 11:07, 30 November 2016 (UTC)
- Support --Jklamo (talk) 15:19, 30 November 2016 (UTC)
- Oppose full automation, unless certain categories of pages will be left alone by bots. I am particularly concerned that #7 would unlink anthroponymy (human name) pages in enwiki, where the main content is a list of people sharing a name. en:MOS:DABNAME distinguishes these from disambiguation pages, even in the many cases where there is not also a disambiguation page for the same name/word. However, in many cases, the equivalent pages are disambiguation pages in other-language wikipedias. – Fayenatic london (talk) 22:58, 1 December 2016 (UTC)
- Point 8 should take care of such issues. --Jura1 (talk) 10:03, 10 December 2016 (UTC)
- Support --Almondega (talk) 11:14, 6 December 2016 (UTC)
- Support --Vogone (talk) 23:59, 11 December 2016 (UTC)
- Support - Agree. DPdH (talk) 10:01, 12 December 2016 (UTC)
View two items at the same time
- Problem: It's hard to copy statements and references from one item to another.
- Who would benefit: Editors that enter data.
- Proposed solution: Provide a UI with opens one item on the left side and another on the right side.
Allow dragging statements/references from one item to the other to copy them. Shift+Drag might move statements/references.
- Phabricator tickets:
- Proposer: ChristianKl (talk) 13:18, 15 November 2016 (UTC)
- Translations: none yet
Community discussion
- This sounds like a good idea. Anything to make it easier to copy statements or references would really be a good thing. – Ajraddatz (talk) 08:26, 16 November 2016 (UTC)
- I wrote some code at gerrit:241296 for a tool based on a similar concept; references can still be moved only along with the statements they belong to, the dragging gesture works to move pieces of data (the Ctrl key must be held down to copy them) and overall it doesn't work well but you can find a demo here --Ricordisamoa 17:54, 19 November 2016 (UTC)
- This is why browsers have tabs, and resizeable windows... Drag-drop sounds like it would be useful, but viewing two items at once on a single page sounds less useful... Thanks. Mike Peel (talk) 22:30, 1 December 2016 (UTC)
- Dragging and dropping between browser windows is likely not possible. Therefore it needs to be in the website UI. ChristianKl (talk) 17:38, 5 December 2016 (UTC)
Voting – View two items at the same time
- Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)
- Support Sadads (talk) 15:11, 28 November 2016 (UTC)
- Support and add possibility to merge them :-) JAn Dudík (talk) 22:21, 28 November 2016 (UTC)
- Support ChristianKl (talk) 16:12, 29 November 2016 (UTC)
- Support yes Jane023 (talk) 11:04, 30 November 2016 (UTC)
- Support --Yiyi (talk) 15:51, 3 December 2016 (UTC)
- Support Richard Nevell (WMUK) (talk) 11:16, 6 December 2016 (UTC)
- Support Tothasze (talk) 09:35, 7 December 2016 (UTC)
- Support - DPdH (talk) 10:12, 12 December 2016 (UTC)
Ability to edit Wikidata from WP and other projects
- Problem: "Wikipedia is the free encyclopedia that anyone can edit". But this is true only if they are able to do it. Since we use Wikidata in Wikipedia, we have more and more articles with empty infoboxes or other similar templates, or hard-to-understand code inserted into the wikitext. If somebody tries to change this information (data) in the article, they realize that it is not possible, neither in wikitext editor nor using Visual Editor. Even many experienced editors have stopped using Wikipedia since they are not able to make the changes they wanted, and felt stupid / too old for it, and they don't want to learn another project (developed for rather technophiles). I've led some edit-a-thons recently and it is hard to explain for newbies, that editing Wikipedia is very easy, but only if you don't want to change the part of the article that's imported from Wikidata. I know that there is a link in the left side to the Wikidata page of the article, but I don't feel this would be an easy to use or final solution.
- Who would benefit: Everybody (new and old editors especially)
- Proposed solution: I would like to have an option to change the data (from Wikidata) in Wikipedia or at least I would like to see a direct link beside every single data which redirect me to the specified Wikidata property (statement, identifier etc) inside the Wikidata item.
- Proposer: Samat (talk) 21:09, 12 November 2016 (UTC)
- Translations: none yet
Community discussion
- I don't see how this could be implemented without massive changes in the UI or in the way Wikipedia works. Even if we ignore cross-references to more than the directly associated Wikidata page: The current Wikipedia editing interface is plain text, while some Wikidata property values don't work as plain text (they are references to other items, they have multiple entries, they need specific formatting, ...). In addition, the plain text is a local thing - you don't want to update the local text every time the Wikidata entry gets modified. Importing the Wikidata user interface could work, then the user can edit the article in one area and edit the Wikidata page in a different area, but that is not very intuitive either and it would need a completely new user interface. --mfb (talk) 12:18, 14 November 2016 (UTC)
- This is doable, even though it probably requires a lot of development. A good example is how Wikivoyage allows readers to edit Wikidata information through a user-friendly popup, see screenshot. Syced (talk) 15:46, 14 November 2016 (UTC)
- I think this needs proper implementation of constraints first. Otherwise I would expect a lot of wrong data to be entered when multiple items have the same name. ChristianKl (talk) 13:06, 15 November 2016 (UTC)
- A further problem seems to be that different Wikipedia's use different software to interact with Wikidata. ChristianKl (talk) 13:10, 15 November 2016 (UTC)
- wikidata literacy is a problem, it takes at least 3-4 messages per wikidata-newbie to let them understand how wikidata kinda works (basically read the item, make a manual edit, understand what is an Identifer...), and this even if the platform they are active has a more robust wikidata diffusion and they kinda got the concept that wikidata exists. More than 50%-60% of them don't even understand how the crosswikilink interface actually works (for example they are totally unaware they leave edits on wikidata when they connect pages between different language editions). We hence need to address the problem also from the software side, as the problem of this literacy is not fully understood by the vast majority or even worse monopolized by few users ("they ask me", "they ask just here") which is slightly anti-wiki. Wikidata should be an opportunity to increase the potentialities of users, not to reduce it. So I morally support every attempt to reduce the gap.--Alexmar983 (talk) 05:29, 16 November 2016 (UTC)
- I think a key thing to implement here is to make easy the amendment of an already inserted piece of WikiData without users having to leave Wikipedia. I think the actual insertion of it will remain a technical task and is less of a concern to fix in this respect. Sillyfolkboy (talk) 00:18, 18 November 2016 (UTC)
- Some gadgets with a similar aim are already partially functional, like fr:User:0x010C/script/DataboxEditor.js and ru:Wikipedia:WE-Framework: their developers would certainly have good ideas about this. Oliv0 (talk) 09:03, 20 November 2016 (UTC)
- Note: There's some ongoing research into this, in these links. Quiddity (WMF) (talk) 23:22, 24 November 2016 (UTC)
- Also some related discussion in phab:T112987 which was out of last year's Make it easy to build infoboxes that display information from wikidata. Quiddity (WMF) (talk) 23:26, 24 November 2016 (UTC)
Voting – Ability to edit Wikidata from WP and other projects
- Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)
- Support --Titou (talk) 08:51, 28 November 2016 (UTC)
- Support--Gareth (talk) 12:08, 28 November 2016 (UTC)
- Support Sadads (talk) 15:12, 28 November 2016 (UTC)
- Support Even though it's unclear at the moment exactly how this could work, I very much support the thinking behind it. We should be working towards greater integration. MichaelMaggs (talk) 20:40, 28 November 2016 (UTC)
- Support Note, this is not for a specific solution.— Jeblad 01:57, 29 November 2016 (UTC)
- Support more attention to better integration, specifically. Editing Wikidata is IMHO easier than editing Wikipedia, but I can totally see that the transition between both is very confusing. Spinster (talk) 15:41, 29 November 2016 (UTC)
- Support --Mikey641 (talk) 18:27, 29 November 2016 (UTC)
- Support however the UI would need to be quite different from the traditional wikipedia text edit UI... ArthurPSmith (talk) 18:51, 29 November 2016 (UTC)
- Support --Telaneo (User talk page) 22:04, 29 November 2016 (UTC)
- Support Blue Elf (talk) 00:05, 30 November 2016 (UTC)
- Support, at first for a single English Wikipedia infobox such as Infobox Person. UI should work on mobile too. Syced (talk) 07:24, 30 November 2016 (UTC)
- Support Alexei Kopylov (talk) 08:16, 30 November 2016 (UTC)
- Oppose unless this becomes like the Commons interface for non-English Wikipedians, where they click the upload and get dumped into Commons. Now that people have got used to that, they can get used to it with Wikidata too. Jane023 (talk) 12:26, 30 November 2016 (UTC)
- Support Trizek from FR 19:59, 30 November 2016 (UTC)
- Support --Fixuture (talk) 21:20, 30 November 2016 (UTC)
- Support --Ryan • (talk) • 23:22, 30 November 2016 (UTC)
- Support --Vachovec1 (talk) 20:51, 1 December 2016 (UTC)
- Support --FocalPoint (talk) 20:51, 1 December 2016 (UTC)
- Support Mike Peel (talk) 22:30, 1 December 2016 (UTC)
- Support --WikedKentaur (talk) 23:22, 1 December 2016 (UTC)
- Support —Patrug (talk) 00:37, 2 December 2016 (UTC)
- Support NMaia (talk) 00:43, 2 December 2016 (UTC)
- Support Libcub (talk) 03:47, 2 December 2016 (UTC)
- Support --Geraki TL 06:52, 2 December 2016 (UTC)
- Support Oliv0 (talk) 07:14, 2 December 2016 (UTC)
- Support Draceane (talk) 11:01, 2 December 2016 (UTC)
- Support —Jc86035 (talk) 11:22, 2 December 2016 (UTC)
- Support There have been a few complaints that the way to alter Wikidata information is not intuitive and requires you to hop between websites. Jo-Jo Eumerus (talk, contributions) 15:57, 2 December 2016 (UTC)
- Support --Framawiki (talk) 20:53, 2 December 2016 (UTC)
- Support – Ajraddatz (talk) 23:08, 2 December 2016 (UTC)
- Support – Susanna Ånäs (Susannaanas) (talk) 11:18, 3 December 2016 (UTC)
- Support Pamputt (talk) 10:44, 4 December 2016 (UTC)
- Support --Julien1978 (d.) 12:05, 4 December 2016 (UTC)
- Support -- T.seppelt (talk) 16:05, 4 December 2016 (UTC)
- Support --By erdo can • TLK 17:01, 4 December 2016 (UTC)
- Support--Runner1928 (talk) 02:39, 5 December 2016 (UTC)
- Support --Epìdosis 20:00, 5 December 2016 (UTC)
- Support --Kurt Jansson (talk) 22:30, 5 December 2016 (UTC)
- Support I support the idea of more deep integration between Wikipedia and Wikidata. It would be really nice to do it the same way as interwiki data were changed. I also think that wikipedians should learn to use wikidata. So I'd like this divided into 2 proposals: 1. Redesign templates and infoboxes. 2. Improve experience of people who are not aware about Wikidata. --Vanuan (talk) 06:35, 6 December 2016 (UTC)
- Support--Ranjithsiji (talk) 11:22, 6 December 2016 (UTC)
- Support Pabouk (talk) 13:08, 6 December 2016 (UTC)
- Support I think this is the most important proposal of the year. There are already multiple projects to develop this functionality, and from Wikidata's inception this was an imagined feature. Perhaps now is time. Blue Rasberry (talk) 18:29, 6 December 2016 (UTC)
- Support ★ → Airon 90 09:33, 7 December 2016 (UTC)
- Support --Afernand74 (talk) 11:23, 7 December 2016 (UTC)
- Support SamanthaNguyen (talk) 03:03, 8 December 2016 (UTC)
- Support would be very useful --LT910001 (talk) 06:01, 8 December 2016 (UTC)
- Support — Rhododendrites talk \\ 15:00, 8 December 2016 (UTC)
- Support --Fixer88 (talk) 20:59, 8 December 2016 (UTC)
- Support --Arnd (talk) 13:52, 9 December 2016 (UTC)
- Support --Tarjeimo (talk) 23:13, 9 December 2016 (UTC)
- Support Blue Elf (talk) 23:38, 9 December 2016 (UTC)
- Support --DangSunM (talk) 01:54, 10 December 2016 (UTC)
- Support--Nizil Shah (talk) 06:57, 10 December 2016 (UTC)
- Support--Kaitil (talk) 09:37, 10 December 2016 (UTC)
- Support --Kjersti Lie (talk) 11:36, 10 December 2016 (UTC)
- Support --Waldir (talk) 12:11, 10 December 2016 (UTC)
- Support -- Gabriel Kielland (talk) 13:33, 10 December 2016 (UTC)
- Support Stigmj (talk) 20:27, 10 December 2016 (UTC)
- Support This is years overdue. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 18:31, 11 December 2016 (UTC)
- Support--Ezzex (talk) 20:14, 11 December 2016 (UTC)
- Support Ulflarsen (talk) 00:08, 12 December 2016 (UTC)
- Support no-brainer RadiX∞ 02:27, 12 December 2016 (UTC)
- Support - DPdH (talk) 10:13, 12 December 2016 (UTC)
- Support --Elitre (talk) 18:56, 12 December 2016 (UTC)
- Support --KuboF (talk) 22:34, 12 December 2016 (UTC)
- Support, this will kill an annoying argument "this is imported from Wikidata and some guys decided something I don't agree with, how can I remove this" by more prominent notice that Wikidata is editable as well — NickK (talk) 23:24, 12 December 2016 (UTC)
- Support --Yann (talk) 23:52, 12 December 2016 (UTC)
- Support (disclaimer: I am the initiator) -- Samat (talk) 23:56, 12 December 2016 (UTC)
Ability to reuse references in Wikidata
- Problem: Even if the same reference is used for every item of a Wikidata entry, the reference data has to be entered separately for each field.
- Who would benefit: People entering references in Wikidata.
- Proposed solution: Have a selection drop-down in every field that displays references already entered in that Wikidata page.
- Phabricator tickets:
- Proposer: Aracali (talk) 20:52, 13 November 2016 (UTC)
Community discussion
Aracali, are you aware of the DuplicateReferences gadget (can be turned on in your Wikidata preferences)? If you are, do you propose something more extensive than that? I agree references are still cumbersome to add in Wikidata, but that gadget helps a lot. Spinster (talk) 20:21, 15 November 2016 (UTC)
- Part of the problem might be that these gadgets are not well-advertized. Do you know if there is a help page that lists reference-specific ones by function? – Ajraddatz (talk) 08:25, 16 November 2016 (UTC)
- No, I was not aware of that. Perhaps it should be "on" by default. The documentation is pretty sparse, and when I tried to use the gadget I was surprised when it automatically saved the change after pasting the reference. I was expecting that it would add it in edit mode, so items such as page number could be changed, and the user would be asked before saving. Thanks for the pointer, Aracali (talk) 03:04, 17 November 2016 (UTC)
- Thank you for this proposal!!! I didn't know that there is a gadget/tool/artifact/cacharro/parato that allows to use one reference once and again. By the way, how do you add a page/volume number? I've been referencing with Enciclopedia Espasa (100+ volumes) and Britannica (30+ ones) and all I could say is It's (somewhere) there. Definitely documentation is pretty sparse, references are still cumbersome to add in Wikidata and these gadgets are not well-advertized. B25es (talk) 17:29, 17 November 2016 (UTC)
- Ah. The needs are clearer to me. Yes, it would be excellent if this functionality would be integrated in the default interface. I think this is also related to the WikiCite project, but I have not explored that very much yet. Spinster (talk) 18:54, 17 November 2016 (UTC)
Voting – Ability to reuse references in Wikidata
- Support--Gareth (talk) 12:10, 28 November 2016 (UTC)
- Support--Aracali (talk) 14:57, 28 November 2016 (UTC)
- Support Sadads (talk) 15:13, 28 November 2016 (UTC)
- Support Spinster (talk) 15:44, 29 November 2016 (UTC)
- Support --YMS (talk) 16:26, 29 November 2016 (UTC)
- Support ArthurPSmith (talk) 18:52, 29 November 2016 (UTC)
- Support -- Mushroom (talk) 22:12, 29 November 2016 (UTC)
- Support Jane023 (talk) 12:27, 30 November 2016 (UTC)
- Support --Nouill (talk) 14:12, 1 December 2016 (UTC)
- Support B25es (talk) 17:56, 1 December 2016 (UTC)
- Support --AmaryllisGardener talk 19:05, 1 December 2016 (UTC)
- Support Mike Peel (talk) 22:31, 1 December 2016 (UTC)
- Support Libcub (talk) 03:48, 2 December 2016 (UTC)
- Support --Geraki TL 06:53, 2 December 2016 (UTC)
- Support Oliv0 (talk) 07:28, 2 December 2016 (UTC)
- Support --Entbert (talk) 15:15, 2 December 2016 (UTC)
- Support I'm also sorely missing a way to reuse a reference on multiple items. - Nikki (talk) 18:22, 2 December 2016 (UTC)
- Support. Matiia (talk) 23:14, 2 December 2016 (UTC)
- Support – Susanna Ånäs (Susannaanas) (talk) 11:18, 3 December 2016 (UTC)
- Support Pamputt (talk) 10:44, 4 December 2016 (UTC)
- Support -- Marcus Cyron (talk) 12:06, 4 December 2016 (UTC)
- Support -- the wub "?!" 13:34, 4 December 2016 (UTC)
- Support --By erdo can • TLK 17:01, 4 December 2016 (UTC)
- Support --HHill (talk) 10:56, 5 December 2016 (UTC)
- Support --Bamyers99 (talk) 18:59, 5 December 2016 (UTC)
- Support Chewbacca2205 (talk) 19:53, 5 December 2016 (UTC)
- Support --Epìdosis 20:00, 5 December 2016 (UTC)
- Support Beyond duplicating the references I suppose this means WikiCite collections of all references also. Blue Rasberry (talk) 18:30, 6 December 2016 (UTC)
- Support Jianhui67 talk★contribs 11:29, 7 December 2016 (UTC)
- Support --M11rtinb (talk) 16:21, 7 December 2016 (UTC)
- Support SamanthaNguyen (talk) 03:03, 8 December 2016 (UTC)
- Support On enwiki people keep carrying on that "OMG! Wikidata is full of unreferenced stuff!" It's often overblown, but it is a problem, and a great deal of the problem comes from the fact that the interface is tedious and fiddly to use. Opabinia regalis (talk) 06:55, 9 December 2016 (UTC)
- Support This is a no-brainer. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 18:31, 11 December 2016 (UTC)
- Support So long I've been waiting for this. RadiX∞ 02:31, 12 December 2016 (UTC)
- Support - DPdH (talk) 10:14, 12 December 2016 (UTC)
- Support, although I think a gadget is available for this — NickK (talk) 23:25, 12 December 2016 (UTC)
- Support --Yann (talk) 23:52, 12 December 2016 (UTC)
Allow looking up Entities by specific property value
- Problem: :#It is hard to match Wikidata records with pages on other wikimedia projects or 3rd party services without ability to look up entities based on the external identifiers associated with them. For example if I know VIAF number to be "2481716" I would like to be able to look up d:Q728201 using Lua.
- Many Commons pages in different namespaces might need to access Wikidata properties, but only one can be connected by a sitelink. Currently most pages on Commons that need to access Wikidata use hardwired entry q-code which create maintenance issues to keep them in synch with links from Wikidata to Commons. A better solution would be ability to look up entities based on the values of specific properties. For example Lua code on c:Institution:Archéa page should be able to look up d:Q2860590 as entry that has P1612 set to "Archéa".
- Who would benefit: People trying to link to Wikidata. Users on projects that can benefit from linking to Wikidata.
- Proposed solution: Create Lua function mw.wikibase.getEntityByProperty(property, value) that can look up an entity by a value of specified property. There are tools like resolver or multibeacon that can do that, but I would like to use it from Lua. I think it would be wise to implement it only for properties that have Distinct values constraint. Other restrictions on which property that applies to might also be needed.
- More comments: Alternative approach to problem of Commons pages needing hardwired q-codes to access Wikidata properties was to create items for them on Wikidata that redirect to the main article item where the properties are kept. Many commons category pages are connected through sitelinks to category items which redirect through property P301 to item with properties. The idea would be to extend this approach to many more categories and commons pages in Creator and Institution namespaces. The issue with this approach is that it creates a lot of extra Wikidata items that have to be maintained and kept in synch with each other. Currently if a category is renamed on Commons than that name has to be replaced in 3 different places (category item sitelink, category item P373 and article item P373). Also maintenance of P373 is not keeping up as we have 209,687 Distinct value constraint violations. I would like to avoid creating any items that only hold information kept in other item properties.
- Phabricator tickets:
- Proposer: Jarekt (talk) 14:23, 17 November 2016 (UTC)
- Translations: none yet
Community discussion
- @Smalyshev (WMF): Thoughts? Would it be possible to call WDQS from Lua? Would that be a terrible idea (due to lag issues)? Ryan Kaldari (WMF) (talk) 00:17, 23 November 2016 (UTC)
- We are currently in the deign phase of allowing people to create automated lists on Wikipedia and co based on queries to Wikidata. This is the solution to a much larger problem. In addition we might want to have specialized indexes for identifiers for example and expose them directly without going through sparql. Nothing concrete yet though. --Lydia Pintscher (WMDE) (talk) 08:16, 23 November 2016 (UTC)
- I'm not sure whether it would be a good idea. There are two things to consider here:
- Roundtrip time (queries can take really long, and I'm not sure putting those in Lua - e.g. callable from parser) is good.
- Result sizes - query can return millions of items, what would we do with them?
- If we're looking at very limited subset - like matching by VIAF number or another authority property - it can be made to work, maybe even with faster triple-fragments query. But anything more complex really needs much more careful approach, it can explode rather quickly. --Smalyshev (WMF) (talk) 20:45, 23 November 2016 (UTC)
Voting – Allow looking up Entities by specific property value
- Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)
- Support --Jarekt (talk) 03:21, 30 November 2016 (UTC)
- Support OMG yesssss! That I can't do this drives me nuts, whether it's with WLM monument numbers, painting inventory numbers or even VIAF numbers. Jane023 (talk) 12:28, 30 November 2016 (UTC)
- Support B25es (talk) 18:02, 1 December 2016 (UTC)
- Support Libcub (talk) 03:49, 2 December 2016 (UTC)
- Support --Geraki TL 06:53, 2 December 2016 (UTC)
- Support -Entbert (talk) 15:16, 2 December 2016 (UTC)
- Support --Epìdosis 20:01, 5 December 2016 (UTC)
- Support --Jklamo (talk) 14:41, 9 December 2016 (UTC)
- Support -- FriedhelmW (talk) 19:06, 9 December 2016 (UTC)
- Support --NaBUru38 (talk)
Article history integration
- Problem: d:WD:DEVPLAN#Article history integration: for sake of verifiability on Wikipedia, there should be an option to show in the history of a Wikipedia article the Wikidata changes actually displayed in the article. Verifiability and control in Wikipedia of what is displayed from Wikidata has appeared long ago as an important question on the French Wikipedia, and has often been the proposed solution answering doubts and controversies about Wikidata data. A RfC on the German Wikipedia has decided for sake of verifiability to display only Wikidata data with a real source, and in return did not demand a better control of Wikidata data eg. in watchlist; then the corresponding RfC on the French Wikipedia did not include the question of a better control and rejected displaying only sourced data, making the question of Wikidata verifiability on Wikipedia all the more high-priority.
- Who would benefit: People who want to see what happened in a Wikipedia article including what is displayed using Wikidata, for instance in order to have a better check after they have seen a Wikidata change in their watchlist.
- Proposed solution: See the Phabricator ticket, and on the French Wikipedia the gadget fr:User:H4stings/wef-history.js (described here in French) by User:H4stings, which still needs improvements for a better integration and adaptation to exact needs.
- Phabricator tickets: phab:T42358
- Proposer: Oliv0 (talk) 09:38, 20 November 2016 (UTC)
- Translations: none yet
Community discussion
- I am skeptical how much it will benefit us if we replicate the Wikidata item history approx. 800 times. I don't have anything against a gadget for users who want this feature, but I don't see why this is something to add to the extension. --Vogone (talk) 23:50, 28 November 2016 (UTC)
- The Wikidata item history is to be used in the history of only one Wikipedia article, the corresponding one, why 800? Oliv0 (talk) 09:40, 29 November 2016 (UTC)
- Because up to approx. 800 wikis can be linked with a single Wikidata item. --Vogone (talk) 23:02, 2 December 2016 (UTC)
- Probably no more than 10 wikis ever display the data from a corrresponding Wikidata item (mainly in infoboxes), but more importantly, an extract of the Wikidata history showing only what is actually displayed on the wiki, integrated chronologically into the wiki article history with the same formatting, would be very beneficial to be able to view or search all of what readers actually see on a given Wikipedia page using Wikidata. Oliv0 (talk) 11:08, 4 December 2016 (UTC)
- Because up to approx. 800 wikis can be linked with a single Wikidata item. --Vogone (talk) 23:02, 2 December 2016 (UTC)
- The Wikidata item history is to be used in the history of only one Wikipedia article, the corresponding one, why 800? Oliv0 (talk) 09:40, 29 November 2016 (UTC)
- I still don't know how Wikidata values are imported to articles. I mean, if on February 2016 an article says "the current population of the vilalge is 524 people" taken from a property, and on February 2017 it changes to 579 people, what happens when I check the history page? Do I get the value of the respective date, or do I get the current value? --NaBUru38 (talk) 21:59, 10 December 2016 (UTC)
Voting – Article history integration
- Support--Gareth (talk) 12:18, 28 November 2016 (UTC)
- Support ChristianKl (talk) 16:13, 29 November 2016 (UTC)
- Support Cette demande est déjà très ancienne
, elle ne date pas même pas d'août 2015 mais de janvier et février 2014. Les choix techniques faits pour l'utilisation des données Wikidata dans Wikipédia rendent la mise en oeuvre de cette proposition indispensable pour permettre la maîtrise et le suivi du contenu d'une Wikipédia par ses contributeurs. O.Taris (discuter) 22:04, 30 November 2016 (UTC)- Rough translation by Trizek from FR : that request is already pretty old
, not from August 2015 but from January and February 2014 (diffs in French). The technical choices made for the use of the Wikidata data in Wikipedia make the implementation of this proposal indispensable to allow control and monitoring of Wikipedia contents by its contributors.
- Rough translation by Trizek from FR : that request is already pretty old
- Support Aidera grandement à comprendre ce qui est affiché dans l'article. Pamputt (talk) 07:31, 1 December 2016 (UTC)
- Support Absolutely necessary. --Tractopelle-jaune (talk) 11:02, 1 December 2016 (UTC)
- Support NMaia (talk) 00:45, 2 December 2016 (UTC)
- Support Oliv0 (talk) 07:29, 2 December 2016 (UTC)
- Support Trizek from FR 13:53, 2 December 2016 (UTC)
- Support --Cbyd (talk) 12:23, 3 December 2016 (UTC)
- Support Pamputt (talk) 10:45, 4 December 2016 (UTC)
- Support. --Julien1978 (d.) 12:00, 4 December 2016 (UTC)
- Support Psemdel (talk) 19:35, 5 December 2016 (UTC)
- Support --M11rtinb (talk) 16:21, 7 December 2016 (UTC)
- Support SamanthaNguyen (talk) 03:02, 8 December 2016 (UTC)
- Support, of course! Bob Saint Clar (talk) 21:15, 12 December 2016 (UTC)
Copy/paste statements of an item
- Problem: Sometimes items need to be split or a series of items created and it would be nice to be able to copy paste the labels and/or statements easily
- Who would benefit: All Wikidabata editors using the standard user interface creating items by hand (rather than through quick statements or some other auto-creation method)
- Proposed solution: See my comments on improvements to the "Duplicate this item" gadget. This proposal is for a gadget separate from that menu item that allows copy/paste to duplicate single statements (this would be especially useful for the "depicts" statement, which often includes many reusable tags)
- Phabricator tickets:
- Proposer: Jane023 (talk) 08:29, 15 November 2016 (UTC)
- Translations: none yet
Community discussion
- In the phase of the migration of interwikis to Wikidata, a tool which allowed to copy and paste wikitext to/from Wikidata became quite popular. Nemo 08:39, 15 November 2016 (UTC)
- More or less phab:T149905. I support it. --Melderick (talk) 22:44, 20 November 2016 (UTC)
Voting – Copy/paste statements of an item
- Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)
- Support --Izno (talk) 01:20, 29 November 2016 (UTC)
- Support --Melderick (talk) 13:49, 29 November 2016 (UTC)
- Support -- Stryn (accidentally unsigned)
- Support as proposer, Jane023 (talk) 11:05, 30 November 2016 (UTC)
- Support Sadads (talk) 15:09, 30 November 2016 (UTC)
- Support Trizek from FR 20:00, 30 November 2016 (UTC)
- Support Mike Peel (talk) 22:32, 1 December 2016 (UTC)
- Support NMaia (talk) 00:45, 2 December 2016 (UTC)
- Support Libcub (talk) 03:51, 2 December 2016 (UTC)
- Support --Epìdosis 20:03, 5 December 2016 (UTC)
- Support Jianhui67 talk★contribs 11:24, 7 December 2016 (UTC)
- Support SamanthaNguyen (talk) 03:01, 8 December 2016 (UTC)
- Support Ayack (talk) 12:08, 9 December 2016 (UTC)
- Support --Jklamo (talk) 14:41, 9 December 2016 (UTC)
- Support --NaBUru38 (talk)
Create infobox for books in Wikipedia
- Problem: There is a lot of bibliographic data and properties in Wikidata, however this cannot be used in Wikipedia because there is no infobox capable of displaying the rich data model (see: d:Wikidata:WikiProject_Books).
- Who would benefit: Editors who work with bibliographic data. Readers.
- Proposed solution: create a Lua module that can display information like w:fr:Modèle:Infobox_Livre (it can show a work and its translation), taking into account that in Wikidata the bibliographic information is separated in two different items. Import the data into wikidata using bots (if that hasn't been done already).
- Proposer: Micru (talk) 14:22, 8 November 2016 (UTC)
- Translations: none yet
Community discussion
- @Micru: Could you elaborate on the specific needs for this infobox, please? We have Module:Wikidata on enwp, which is used in infoboxes such as en:Template:Infobox telescope (see en:South Pole Telescope for an example in action) - does that have the features that are needed for this infobox, or does the translation angle make things more complex? Thanks. Mike Peel (talk) 23:17, 9 November 2016 (UTC)
- @Mike Peel: This infobox in particular takes data from two different items (connected with the property "edition"). The problem is that there might be several editions for the same language, so it would be interesting if the infobox could select all the items to show data from. Or it could be possible that there is only one preferred edition and some others not preferred, in that case it could either offer links to the data items, or offer the information in a collapsed box.--Micru (talk) 07:08, 10 November 2016 (UTC)
- I don't thing we need an infobox for book, we need a lua system which is optimized for data extraction from and allows the building of infoboxes. I just fear that requiring specific infoboxes will just create different lua systems (with one or several modules) for infoboxes and later will be a nightmare to maintain. Snipre (talk) 05:47, 10 November 2016 (UTC)
- @Snipre: If your proposed system can handle items that have subitems, then I am fine with it. An additional fear is that by requesting too much of development nothing will get done. It could start small with this complex case, and then add more features from there.--Micru (talk) 07:08, 10 November 2016 (UTC)
- Ongoing concern that this project is focusing backwards. The assumption is that the rich data is in Wikidata, whereas the rich data is probably more likely to be found on Wikipedia at this point (yes I am assuming English Wikipedia). So creating something that would be a large loss of valuable data -- unless this loss of data can be addressed -- is non-ideal. Wikidata does not have the ability to create full citations, so how would citations be linked in these infoboxes? I like the concept, am concerned with implementation, continued recreation of the wheel, and loss of data. -- Erika aka BrillLyle (talk) 19:20, 10 November 2016 (UTC)
- @BrillLyle: My reading of this is that this infobox would use data from Wikidata if possible and otherwise would fall back to local data. Is that correct? @Snipre: This is perhaps also a good reason to limit this proposal to the book infobox, because bibliographic data is easier to represent fully in Wikidata (than say biographical data with lots of variations and citations etc.). Sam Wilson 00:38, 11 November 2016 (UTC)
- @Samwilson: Either way, still concern about the loss of bibliographic data. I would posit also, very strongly, that Wikidata has a heck of a lot LESS biographical information than Wikipedia does. I disagree on that point, especially because there is no ability for Wikidata right now to carry over full citations that exist on Wikipedia that could be part of these infoboxes. So either way, a basic problem of lossy data. I feel like I am repeating this problem over and over again and no one really cares. -- Erika aka BrillLyle (talk) 01:40, 11 November 2016 (UTC)
- @BrillLyle: Sorry, I didn't mean that there's more biographical data on Wikidata, actually the opposite: that we should look at bibiliographic data as a better starting realm because it's (hopefully) easier to get right. But perhaps we need to start talking about exactly what data is required, rather than general concepts.
For example, Wikipedia:Template:Infobox book (and I suspect most other book infoboxes) has a 'pub_date' attribute, which is the date of first publication. This is P577 publication date, and when it's an attribute of a work-level item, it refers to the publication date of the first edition — and so we can easily say that it is the thing we want to display in the infobox. Are there situations in which doing so would be wrong?
An example of the use of this property could be en:Pride and Prejudice: the infobox says "Publication date: 28 January 1813" and has no citation (the citation for this is given in the article text proper, further down the article). The matching Wikidata:Q170583#P577 has the same date, and a citation to the same source.
I know this is a simple example, but maybe it helps to be specific. And really: if all we do is shift publication dates and no other attributes into Wikidata, we'll be better off than we are now! Because then we can pull those dates in else where, and there will be only one place to change them (for example, it seems that it was actually the 27th of January that the printer started sending out copies of Pride and Prejudice…). Sam Wilson 08:30, 11 November 2016 (UTC)
- @BrillLyle: Sorry, I didn't mean that there's more biographical data on Wikidata, actually the opposite: that we should look at bibiliographic data as a better starting realm because it's (hopefully) easier to get right. But perhaps we need to start talking about exactly what data is required, rather than general concepts.
- @Samwilson: Either way, still concern about the loss of bibliographic data. I would posit also, very strongly, that Wikidata has a heck of a lot LESS biographical information than Wikipedia does. I disagree on that point, especially because there is no ability for Wikidata right now to carry over full citations that exist on Wikipedia that could be part of these infoboxes. So either way, a basic problem of lossy data. I feel like I am repeating this problem over and over again and no one really cares. -- Erika aka BrillLyle (talk) 01:40, 11 November 2016 (UTC)
- @BrillLyle: My reading of this is that this infobox would use data from Wikidata if possible and otherwise would fall back to local data. Is that correct? @Snipre: This is perhaps also a good reason to limit this proposal to the book infobox, because bibliographic data is easier to represent fully in Wikidata (than say biographical data with lots of variations and citations etc.). Sam Wilson 00:38, 11 November 2016 (UTC)
Voting – Create infobox for books in Wikipedia
- Support Libcub (talk) 03:52, 2 December 2016 (UTC)
- Strong Oppose - see this discussion for reasons why. In short, this was already tried on English Wikipedia and caused several problems that are not addressed by this proposal. Nikkimaria (talk) 23:18, 3 December 2016 (UTC)
Datatype for Enter time data as Hours:Minutes:Seconds
- Note: I have amended this proposition from a "datatype" for the format to simply a way of entering data in that format, which is the only problem my proposition seeks to resolve
- Problem: WikiData is missing a key real world
datatypeform of data for time: hours, minutes and seconds (i.e. HH:MM:SS).
At the moment, relevant lengths of time are displayed in seconds (see example). While technically correct, the current display and input of this are nonsensical for people; no one can easily comprehend the length of a race lasting 17,039 seconds. This is key inhibitor for any contributor adding such time data. In particular, race times across all sports are affected, but also data on any time-based record longer than a few minutes.
- Who would benefit: This change would allow users to easily input time data into WikiData in a format which is readily intelligible to them and reflects the sources used.
- As time is consistent across languages, Wikidata could in theory greatly reduce maintenance overheads for time data which changes rapidly, for example Michael Phelps's personal record times. (As it stands, if Michael Phelps sets a new personal best, then all 88 of Wikipedia biographies will need updating individually.)
- Proposed solution: Create
new time datatype (or mask) that allows usersa way to input a length of time in the format HH:MM:SS and which shows that format at the front end. This should allow for milliseconds also. Presumably this would be stored at database level still in the seconds format (?).
- Phabricator tickets:
- Proposer: Sillyfolkboy (talk) 00:07, 18 November 2016 (UTC)
- Translations: none yet
Community discussion
Just a quick analysis:
- P2781 ("race time") is apparently fine in terms of data stored, it's just that its format makes it awkward at best and unusable at worst in many situations (more or less all race times greater than one minute, as already noted).
- The current format is equally bad for data entry and display, so both aspects of the problem should be addressed.
- Generally speaking, this issue applies not only to P2781, but also to P2047 ("duration"). A general solution (e.g. the one that encompasses formats other than HH:MM:SS) would enhance not only race times, but all durations. GregorB (talk) 11:34, 18 November 2016 (UTC)
- There is a ticket for this at phab:T145532 --Jura1 (talk) 20:33, 20 November 2016 (UTC)
Voting – Datatype for Hours:Minutes:Seconds
- Support--Wesalius (talk) 08:19, 28 November 2016 (UTC)
- Support SamanthaNguyen (talk) 22:31, 28 November 2016 (UTC)
- Support ChristianKl (talk) 16:05, 29 November 2016 (UTC)
- Support, though I'd be perfectly happy with a mask allowing h:m:s interface rather than an outright new datatype. StevenJ81 (talk) 16:57, 29 November 2016 (UTC)
- Support definitely needed ArthurPSmith (talk) 17:36, 29 November 2016 (UTC)
- Support --Mikey641 (talk) 18:21, 29 November 2016 (UTC)
OpposeLet's have as few datatypes as possible, this one would just be a duplicate to the quantity datatype. 61 seconds or 1 minute 1 second... who cares? Matěj Suchánek (talk) 19:54, 29 November 2016 (UTC)- The usability is better when the user doesn't see 23,522 seconds but 6 hours 32 minutes 2 seconds. ChristianKl (talk) 11:17, 1 December 2016 (UTC)
- Now that the proposal has been ammended, I'm Neutral about it. Matěj Suchánek (talk) 21:24, 11 December 2016 (UTC)
- Oppose new datatype. This is just quantity using multiple convertible unit types. Storing it as a completely separate type of thing is the wrong way to go about this, imo. --Yair rand (talk) 22:01, 29 November 2016 (UTC)
- @Yair rand and Matěj Suchánek: How would I sensibly go about saying some marathon length was 6 hours 32 minutes 2 seconds and some hundredths of a second long using the present quantity data type? --2601:14A:C100:9A40:C58A:9D49:8120:DD39 05:04, 30 November 2016 (UTC)
- 6 × 3,600 + 32 × 60 + 2 = 23,522 seconds is just the same thing. Matěj Suchánek (talk) 13:25, 30 November 2016 (UTC)
- @Yair rand and Matěj Suchánek: How would I sensibly go about saying some marathon length was 6 hours 32 minutes 2 seconds and some hundredths of a second long using the present quantity data type? --2601:14A:C100:9A40:C58A:9D49:8120:DD39 05:04, 30 November 2016 (UTC)
- Support Libcub (talk) 03:55, 2 December 2016 (UTC)
- Oppose new datatype, I would support improving the user interface for the existing data. Multichill (talk) 14:15, 2 December 2016 (UTC)
- Oppose Like Multichill --β16 - (talk) 11:52, 5 December 2016 (UTC)
- @Matěj Suchánek, Beta16, and Multichill: Can I take it that these aren't true opposes, but more like supports for a non-new data type solution to the same problem? I'm not a WikiData typing expert and the technicalities of the solution are of no importance to me, but the form of this survey led me to hazard a guess on how this problem was solvable. Sillyfolkboy (talk) 03:00, 7 December 2016 (UTC)
- Exact. I do not think that a new data type is the best solution. A different view (for example via javascript) of the same data I think is enough. --β16 - (talk) 09:09, 7 December 2016 (UTC)
- @Matěj Suchánek, Beta16, and Multichill: Can I take it that these aren't true opposes, but more like supports for a non-new data type solution to the same problem? I'm not a WikiData typing expert and the technicalities of the solution are of no importance to me, but the form of this survey led me to hazard a guess on how this problem was solvable. Sillyfolkboy (talk) 03:00, 7 December 2016 (UTC)
Oppose This seems to be just a display problem. A preferred display format for a given property should solve it without the need to introduce a new data type. Barcex (talk) 19:52, 8 December 2016 (UTC)- Support Now that the proposal has been ammended I agree with it. Barcex (talk) 18:25, 10 December 2016 (UTC)
- Oppose Confuses data and presentation. Glrx (talk) 03:04, 9 December 2016 (UTC)
- @Glrx and Barcex: I have amended the proposal per your comments. As stated above I have absolutely no interest in specifically using a datatype to solve the problem, I just want any solution to the problem because it's an immense barrier to entering time for 95% of users. Thanks. Sillyfolkboy (talk) 16:58, 10 December 2016 (UTC)
- Support - DPdH (talk) 10:16, 12 December 2016 (UTC)
Easily duplicate parts of an item
- Problem: Sometimes items need to be split or a series of items created and it would be nice to be able to copy labels and statements easily
- Who would benefit: All Wikidata editors using the standard user interface creating items by hand (rather than through quick statements or some other auto-creation method)
- Proposed solution: In the "Duplicate this item" gadget, allow various levels of duplication, such as 1) duplicate this item's labels (useful for example with art collection objects with standard names, such as "Self-portrait"s or "Virgin with Child"s); 2) duplicate this item's descriptions (useful for example with art collection objects with standard descriptions, such as "painting by XXX" or "object in XXX collection"); 3) duplicate all statements stripped of references and external IDs (since the references & IDs are generally referring to a specific item) 4) duplicate all statements with references and IDs (if you are planning on just tweaking the references to apply it to the new item); 4) duplicate single statements (this would be especially useful for the "depicts" statement, which often includes many reusable tags)
- Phabricator tickets:
- Proposer: Jane023 (talk) 08:22, 15 November 2016 (UTC)
- Translations: none yet
Community discussion
- none
Voting – Easily duplicate parts of an item
- Support--Gareth (talk) 12:15, 28 November 2016 (UTC)
- Support ChristianKl (talk) 16:06, 29 November 2016 (UTC)
- Support --YMS (talk) 16:21, 29 November 2016 (UTC)
- Support as proposer, Jane023 (talk) 12:30, 30 November 2016 (UTC)
- Support Libcub (talk) 03:56, 2 December 2016 (UTC)
- Support --Epìdosis 20:04, 5 December 2016 (UTC)
- Support --Ambre Troizat (talk) 11:05, 8 December 2016 (UTC)
- Support --Jklamo (talk) 14:41, 9 December 2016 (UTC)
Easy inter-project linking
- Problem: Adding links between projects (i.e. same language, different project) in Wikidata is tedious. One must find manually the article on the other project, open Wikidata item, and add the link manually
- Who would benefit: All projects mantainers
- Proposed solution: Special:NewItem should have inter-project capabilities, not only inter-language
- Phabricator tickets: phab:T71735
- Proposer: Ninovolador (talk) 13:09, 13 November 2016 (UTC)
- Translations: none yet
Community discussion
- I've never understood why the interlanguage links dialog is disabled after the first link is added. I think there is another report asking wider usage of the same dialog. Nemo 08:37, 15 November 2016 (UTC)
- That's something I also don't understand. It should be quite easy to fix interproject connectivity, because things already work as they should - but only in one very specific situation. It is possible to add a link to any language Wikipedia from projects that don't use language codes (e.g. Commons). But this only works in the direction mentioned in the previous sentence and it fails if the Wikipedia page is already connected to an item. And the full Wikidata item will load if the non-Wikipedia page is already connected to Wikidata. So we need the interlanguage links dialog to appear whenever "edit links" is selected, the dialog needs to be improved to allow proper interproject linking, and creating the link shouldn't fail when the target page is already connected to an item - the link should be added to the existing item. Gareth (talk) 06:54, 22 November 2016 (UTC)
Voting – Easy inter-project linking
- Support as proposer Ninovolador (talk) 11:38, 28 November 2016 (UTC)
- Support JAn Dudík (talk) 22:17, 28 November 2016 (UTC)
- Support -- Gareth (talk) 02:45, 29 November 2016 (UTC)
- Support — StevenJ81 (talk) 16:59, 29 November 2016 (UTC)
- Support --Mikey641 (talk) 18:21, 29 November 2016 (UTC)
- Support Alexei Kopylov (talk) 08:12, 30 November 2016 (UTC)
- Support NMaia (talk) 00:47, 2 December 2016 (UTC)
- Support Libcub (talk) 03:57, 2 December 2016 (UTC)
- Support --Epìdosis 20:05, 5 December 2016 (UTC)
- Support --Ambre Troizat (talk) 11:06, 8 December 2016 (UTC)
- Support MechQuester (talk) 05:43, 9 December 2016 (UTC)
- Support --KuboF (talk) 22:42, 12 December 2016 (UTC)
- Support, linking pages in Wikipedia and Wikisource or Wikinews in the same language should be easier — NickK (talk) 23:29, 12 December 2016 (UTC)
- Support --Yann (talk) 23:54, 12 December 2016 (UTC)
Improve QuickStatements
- Problem: QuickStatements is a very convenient tool to add data in a semi-automatic way, but it lacks several important things:
- No "Stop" button to cancel a batch gone wild
- Only TAB can be used as a delimitor, which is great for people working with spreadsheets, but probably the worse character ever for people working with command line or editing directly in the web page text area. (issue)
- Restarting web browser runs QuickStatements again (issue)
- Who would benefit: People who import data into Wikidata
- Proposed solution: The developer is working on many other things, so it would be great if someone could help him improve the app, all of the source code is at https://bitbucket.org/magnusmanske/wikidata-todo
- Phabricator tickets:
- Proposer: Syced (talk) 04:12, 15 November 2016 (UTC)
- Translations: none yet
Community discussion
- I am afraid that this proposal might not meet the requirements outlined in 2016 Community Wishlist Survey#What happens during the proposal phase?, as three different requests are squashed into one single proposal. --AKlapper (WMF) (talk) 13:00, 15 November 2016 (UTC)
- User:AKlapper (WMF) the proposal is to "Improve QuickStatements", the rest are details better discussed on phabricator or bitbucket that Magnus uses. --Jarekt (talk) 04:59, 17 November 2016 (UTC)
- well to add to the things it would be nice to have in QuickStatements:
- a way to add quantity values with units
- a way to add multi-statement references (currently if you put in multiple S properties they get listed as separate references instead of combining into a single reference with several properties & values)
- ArthurPSmith (talk) 14:54, 16 November 2016 (UTC)
- Support for larger effort of improving and expanding this great tool. I write templates that detect cases where information stored on commons should be moved to wikidata and provide QuickStatements code to move it. Unfortunately the code has be be fixed in a text editor (the tabs issue already mentioned) and has to be pasted by hand to quick statements. I would like to allow other characters than tab to be used as the spacer (maybe one of $ % & @ ) and allow to write URL that prefills QuickStatements with one or more commands. User:Magnus Manske is an one man army of tool development, but it seems to me he could use some help with the maintenance of the existing tools, so he can concentrate on the new tools.--Jarekt (talk) 04:54, 17 November 2016 (UTC)
- Comment I'm all for it, but as a "Version 2" (fixing up the current one would be too messy). I'll need a proper plan, and time. Made a brainstorming page, please participate! --Magnus Manske (talk) 09:32, 17 November 2016 (UTC)
Voting – Improve QuickStatements
- Support--Wesalius (talk) 08:19, 28 November 2016 (UTC)
- Support ChristianKl (talk) 16:06, 29 November 2016 (UTC)
- Support --ValterVB (talk) 18:03, 29 November 2016 (UTC)
- Support -- Mushroom (talk) 22:14, 29 November 2016 (UTC)
- Support --Jarekt (talk) 03:06, 30 November 2016 (UTC)
- Support Syced (talk) 07:13, 30 November 2016 (UTC)
- Support --Jklamo (talk) 15:00, 30 November 2016 (UTC)
- Support Sadads (talk) 15:07, 30 November 2016 (UTC)
- Note - Magnus has ALREADY started work on this, if you would like to help follow the link above for a "pre-alpha" test version to try out with some improvements already... ArthurPSmith (talk) 15:33, 30 November 2016 (UTC)
- Support --Beat Estermann (talk) 09:21, 1 December 2016 (UTC)
- Support Libcub (talk) 03:58, 2 December 2016 (UTC)
- Support —Jc86035 (talk) 11:22, 2 December 2016 (UTC)
- Support --Mr. Ibrahem (talk) 12:28, 2 December 2016 (UTC)
- Support--Runner1928 (talk) 02:41, 5 December 2016 (UTC)
- Support --β16 - (talk) 11:54, 5 December 2016 (UTC)
- Support --Epìdosis 20:06, 5 December 2016 (UTC)
- Support Jianhui67 talk★contribs 11:25, 7 December 2016 (UTC)
- Support --Arnd (talk) 13:49, 9 December 2016 (UTC)
- Support --NaBUru38 (talk)
Improved watchlist integration
- Problem: d:WD:DEVPLAN#Improved watchlist integration: for sake of verifiability and personalised control of recent changes on Wikipedia, the Wikipedia preferences to show Wikidata edits in the watchlist and in the recent changes should allow the user to better choose what s/he wants, like showing only the Wikidata changes actually displayed in the watched articles. Verifiability and control in Wikipedia of what is displayed from Wikidata has appeared long ago as an important question on the French Wikipedia, and has often been the proposed solution answering doubts and controversies about Wikidata data. A RfC on the German Wikipedia has decided for sake of verifiability to display only Wikidata data with a real source, and in return did not demand a better control of Wikidata data eg. in watchlist; then the corresponding RfC on the French Wikipedia did not include the question of a better control and rejected displaying only sourced data, making the question of Wikidata verifiability on Wikipedia all the more high-priority.
- Who would benefit: People who want to see in their watchlist or in recent changes what happens in the Wikipedia articles including what is displayed using Wikidata.
- Proposed solution: See the Phabricator ticket, the user and dev ideas on Wikidata, and on the French Wikipedia the gadget fr:User:H4stings/wef-watchlist.js (described here in French, adapted from the Russian gadget ru:MediaWiki:Gadget-wefwatchlist.js) by User:H4stings, which still needs improvements since it needs a publicly shown copy (or partial copy) of the watchlist and it works only with changes grouped by page in the preferences.
- Phabricator tickets: phab:T90435
- Proposer: Oliv0 (talk) 09:40, 20 November 2016 (UTC)
- Translations: none yet
Community discussion
Good idea - One of the main criticism again WD use in WP is the difficulty to follow change in WD items affecting display of data in WP. An integration of watchlists is necessary. Snipre (talk) 08:42, 22 November 2016 (UTC)