Community Wishlist Survey 2016/Categories/Wikidata

26 proposals, 225 contributors, 484 support votes

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.

Community discussion


Voting – Primary Sources: Don't reload when a claim from the tool gets approved

  1.   Support And I could see this for other edits as well, Sadads (talk) 15:10, 28 November 2016 (UTC)[reply]
  2.   Support --Micru (talk) 16:08, 28 November 2016 (UTC)[reply]
  3.   Support --Izno (talk) 01:25, 29 November 2016 (UTC)[reply]
  4.   Support ChristianKl (talk) 16:08, 29 November 2016 (UTC)[reply]
  5.   Support -- Mushroom (talk) 22:08, 29 November 2016 (UTC)[reply]
  6.   Support --Jklamo (talk) 15:04, 30 November 2016 (UTC)[reply]
  7.   Support --Geraki TL 06:41, 2 December 2016 (UTC)[reply]
  8.   Support--Runner1928 (talk) 02:43, 5 December 2016 (UTC)[reply]
  9.   Support --Epìdosis 20:09, 5 December 2016 (UTC)[reply]
  10.   Support--Nikosguard (talk) 09:24, 6 December 2016 (UTC)[reply]
  11.   Support - DPdH (talk) 21:19, 11 December 2016 (UTC)[reply]

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

Community discussion

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:

ChristianKl (talk) 21:50, 10 November 2016 (UTC)[reply]

Community discussion

@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)[reply]
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)[reply]
  • Something like that seems useful.--Alexmar983 (talk) 05:31, 16 November 2016 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
    • 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)[reply]
  • 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)[reply]

Voting – Show only items that are allowed given the constraints of property

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support--Gareth (talk) 12:03, 28 November 2016 (UTC)[reply]
  3.   Support ChristianKl (talk) 16:09, 29 November 2016 (UTC)[reply]
  4.   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)[reply]
  5.   Support anything to improve suggestions is welcome. Jane023 (talk) 10:48, 30 November 2016 (UTC)[reply]
  6. 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)[reply]
  7.   Oppose per Arthur. --AmaryllisGardener talk 19:03, 1 December 2016 (UTC)[reply]
  8. 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)[reply]
  9.   Support Libcub (talk) 03:42, 2 December 2016 (UTC)[reply]
  10.   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)[reply]
  11.   Support --Entbert (talk) 15:12, 2 December 2016 (UTC)[reply]
  12.   Support -- T.seppelt (talk) 16:04, 4 December 2016 (UTC)[reply]
  13.   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)[reply]
  14.   Support with ArthurPSmith's caveat. --Waldir (talk) 12:10, 10 December 2016 (UTC)[reply]
  15.   Support --NaBUru38 (talk)
  16.   Support --Chrumps (talk) 03:18, 11 December 2016 (UTC)[reply]
  17.   Support -- Gelli1742 (talk) 11:11, 11 December 2016 (UTC)[reply]
  18.   Support - DPdH (talk) 21:19, 11 December 2016 (UTC)[reply]
  19.   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)[reply]
  20.   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 UkraineNickK (talk) 23:21, 12 December 2016 (UTC)[reply]
  21.   Support Obviously. --Yann (talk) 23:51, 12 December 2016 (UTC)[reply]

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)

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)[reply]
  • 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)[reply]
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)[reply]
It is clearly stated in the description: "both on Wikimedia projects and externally". Cheers! Syced (talk) 09:12, 17 November 2016 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 would provide good-enough statistics. Syced (talk) 07:42, 21 November 2016 (UTC)[reply]
Both. They can be split in separate proposals if that makes things clearer. Spinster (talk) 17:02, 23 November 2016 (UTC)[reply]

Voting – Statistics of use of Wikidata's data

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support--Gareth (talk) 12:05, 28 November 2016 (UTC)[reply]
  3.   Support as proposer. Spinster (talk) 15:37, 29 November 2016 (UTC)[reply]
  4.   Support --Mikey641 (talk) 18:26, 29 November 2016 (UTC)[reply]
  5.   Support Jane023 (talk) 10:38, 30 November 2016 (UTC)[reply]
  6.   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)[reply]
  7.   Support Pamputt (talk) 07:34, 1 December 2016 (UTC)[reply]
  8.   Support --Beat Estermann (talk) 09:19, 1 December 2016 (UTC)[reply]
  9.   Support Jsamwrites (talk) 18:39, 1 December 2016 (UTC)[reply]
  10.   Support --AmaryllisGardener talk 19:03, 1 December 2016 (UTC)[reply]
  11.   Support --FocalPoint (talk) 20:49, 1 December 2016 (UTC)[reply]
  12.   Support Mike Peel (talk) 22:27, 1 December 2016 (UTC)[reply]
  13.   Support SamanthaNguyen (talk) 22:57, 1 December 2016 (UTC)[reply]
  14.   Support --WikedKentaur (talk) 23:20, 1 December 2016 (UTC)[reply]
  15. Weak   Support This needs to be done in a way that respects the individual's privacy. NMaia (talk) 00:41, 2 December 2016 (UTC)[reply]
  16.   Support Libcub (talk) 03:43, 2 December 2016 (UTC)[reply]
  17.   Support --Jordi G (talk) 09:05, 2 December 2016 (UTC)[reply]
  18.   Support Draceane (talk) 11:00, 2 December 2016 (UTC)[reply]
  19.   SupportJc86035 (talk) 11:22, 2 December 2016 (UTC)[reply]
  20.   Support--Adert (talk) 22:44, 2 December 2016 (UTC)[reply]
  21.   Support--Pauljmackay (talk) 11:12, 3 December 2016 (UTC)[reply]
  22.   Support--Runner1928 (talk) 02:38, 5 December 2016 (UTC)[reply]
  23.   Support --Epìdosis 20:10, 5 December 2016 (UTC)[reply]
  24.   Support--Nikosguard (talk) 09:21, 6 December 2016 (UTC)[reply]
  25.   Support Richard Nevell (WMUK) (talk) 11:15, 6 December 2016 (UTC)[reply]
  26.   Support Jianhui67 talkcontribs 11:28, 7 December 2016 (UTC)[reply]
  27.   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)[reply]
  28.   Support--David1010 (talk) 20:46, 11 December 2016 (UTC)[reply]
  29.   Support - Can't manage what's not measured. DPdH (talk) 21:20, 11 December 2016 (UTC)[reply]
  30.   Support--Alexmar983 (talk) 03:50, 12 December 2016 (UTC)[reply]
  31.   Support--Mikheil Talk 21:29, 12 December 2016 (UTC)[reply]
  32.   Support more statistics — NickK (talk) 23:21, 12 December 2016 (UTC)[reply]

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]

Community discussion

Voting – Support for Incubator projects

  1.   Support --MF-W 14:20, 28 November 2016 (UTC)[reply]
  2.   Support --Vogone (talk) 14:22, 28 November 2016 (UTC)[reply]
  3.   Support --Steinsplitter (talk) 15:05, 28 November 2016 (UTC)[reply]
  4.   Support --Wolverène 15:18, 28 November 2016 (UTC)[reply]
  5.   Support --StevenJ81 (talk) 15:23, 28 November 2016 (UTC)[reply]
  6.   Support --Micru (talk) 16:09, 28 November 2016 (UTC)[reply]
  7.   Support --Base (talk) 16:16, 28 November 2016 (UTC)[reply]
  8.   Support --GeekEmad (talk) 18:44, 28 November 2016 (UTC)[reply]
    (was support) --Ibrahim khashrowdi (talk) 18:52, 28 November 2016 (UTC)[reply]
    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)[reply]
    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)[reply]
  9.   Support JAn Dudík (talk) 22:21, 28 November 2016 (UTC)[reply]
  10.   Support --Siri111 (talk) 23:04, 28 November 2016 (UTC)[reply]
  11.   Support --Yair rand (talk) 07:02, 29 November 2016 (UTC)[reply]
  12.   Support --Lsanabria (talk) 15:15, 29 November 2016 (UTC)[reply]
  13.   Support SamanthaNguyen (talk) 22:57, 1 December 2016 (UTC)[reply]
  14.   Support NMaia (talk) 00:39, 2 December 2016 (UTC)[reply]
  15.   Support -Mh7kJ (talk) 01:37, 2 December 2016 (UTC)[reply]
  16.   Support Libcub (talk) 03:44, 2 December 2016 (UTC)[reply]
  17.   Support Jmvkrecords (Intra talk) 10:37, 2 December 2016 (UTC).[reply]
  18.   Support - Nikki (talk) 18:20, 2 December 2016 (UTC)[reply]
  19.   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)TCM 19:45, 2 December 2016 (UTC)[reply]
  20.   Support --Framawiki (talk) 20:52, 2 December 2016 (UTC)[reply]
  21.   SupportAjraddatz (talk) 23:08, 2 December 2016 (UTC)[reply]
  22.   Support. Matiia (talk) 23:13, 2 December 2016 (UTC)[reply]
  23.   Support KPFC💬 23:49, 2 December 2016 (UTC)[reply]
  24.   Support the wub "?!" 13:32, 4 December 2016 (UTC)[reply]
  25.   Support --SDKmac (talk) 13:45, 4 December 2016 (UTC)[reply]
  26.   Support --XXnickiXx (talk) 13:51, 4 December 2016 (UTC)[reply]
  27.   Support --Metrophil (talk) 13:52, 4 December 2016 (UTC)[reply]
  28.   Support --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (talk) 13:54, 4 December 2016 (UTC)[reply]
  29.   Support --Kenny McFly (talk) 13:57, 4 December 2016 (UTC)[reply]
  30.   Support --By erdo can • TLK 17:01, 4 December 2016 (UTC)[reply]
  31.   Support -- Freddy2001 talk 18:46, 4 December 2016 (UTC)[reply]
  32.   Support --DCB (talk) 22:15, 4 December 2016 (UTC)[reply]
  33.   Support --Rschen7754 04:44, 5 December 2016 (UTC)[reply]
  34.   Support --Epìdosis 20:11, 5 December 2016 (UTC)[reply]
  35.   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)[reply]
  36.   Support --HakanIST (talk) 06:38, 6 December 2016 (UTC)[reply]
  37.   Support --Liuxinyu970226 (talk) 11:17, 6 December 2016 (UTC)[reply]
  38.   Support Pabouk (talk) 13:13, 6 December 2016 (UTC)[reply]
  39.   Support Jianhui67 talkcontribs 11:29, 7 December 2016 (UTC)[reply]
  40.   Support yes — regards, Revi 06:27, 9 December 2016 (UTC)[reply]
  41.   Support --Kusurija (talk) 20:05, 9 December 2016 (UTC)[reply]
  42.   Support --DangSunM (talk) 01:46, 10 December 2016 (UTC)[reply]
  43.   SupportDerHexer (Talk) 22:58, 10 December 2016 (UTC)[reply]
  44.   Support --Wnme 20:35, 11 December 2016 (UTC)[reply]
  45.   Support--David1010 (talk) 20:47, 11 December 2016 (UTC)[reply]
  46.   Support-- Save the Babies.--Stemoc 02:21, 12 December 2016 (UTC)[reply]
  47.   Support--Shanmugamp7 (talk) 02:22, 12 December 2016 (UTC)[reply]
  48.   Support. RadiX 02:39, 12 December 2016 (UTC)[reply]
  49.   Support Gives more recognition to developing wikis. Ebe123 (Communication | Activity report) 14:55, 12 December 2016 (UTC)[reply]
  50.   Support - Useful. Smile4ever (talk) 18:49, 12 December 2016 (UTC)[reply]
  51.   Support--Mikheil Talk 21:32, 12 December 2016 (UTC)[reply]
  52.   Support --DerMaxdorfer (talk) 22:02, 12 December 2016 (UTC)[reply]
  53.   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)[reply]
  54.   SupportNickK (talk) 23:22, 12 December 2016 (UTC)[reply]

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
Points to cover
  • 1. Complete descriptions with standard text in all languages (already exists)
    • 1a. add missing descriptions
    • 1b. normalize descriptions if possible
  • 2. Merge items with same label in all languages
  • 3. List empty disambiguation items for deletions (items with no sitelinks)
  • 4. Add P31= based on disambiguation categories at Wikidata (partially exists )
  • 5. List problems, solve some automatically
  • 6. Undo incorrect merges
    • 6a. identify by P31 values
  • 7. Ensure sitelinks are disambiguation pages
    • 7a. Disconnect sitelinks that are not disambiguation pages from disambiguation item phab:T144271
    • 7b. Disconnect sitelinks that are disambiguation pages from items that are not disambiguation items (sample)
  • 8. Process disambiguation categories per wiki for most actions
  • 9. Process some actions in two steps: analyze what needs to be done then, maybe a week later, re-analyze what needs to be done and do what still needs to done.
  • 10. Remove description "disambiguation" from items that don't have P31=Q4167410
  • 11. Delete sitelinks that are redirects to disambiguation pages

Community discussion

Voting – Take care of disambiguation items

  1.   Support --YMS (talk) 16:25, 29 November 2016 (UTC)[reply]
  2.   Support --ValterVB (talk) 18:02, 29 November 2016 (UTC)[reply]
  3.   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)[reply]
  4.   Support we could put disambiguation pages on steroids. Jane023 (talk) 11:07, 30 November 2016 (UTC)[reply]
  5.   Support --Jklamo (talk) 15:19, 30 November 2016 (UTC)[reply]
  6.   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)[reply]
    Point 8 should take care of such issues. --Jura1 (talk) 10:03, 10 December 2016 (UTC)[reply]
  7.   Support --Almondega (talk) 11:14, 6 December 2016 (UTC)[reply]
  8.   Support --Vogone (talk) 23:59, 11 December 2016 (UTC)[reply]
  9.   Support - Agree. DPdH (talk) 10:01, 12 December 2016 (UTC)[reply]

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:

Community discussion

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

Voting – View two items at the same time

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support Sadads (talk) 15:11, 28 November 2016 (UTC)[reply]
  3.   Support and add possibility to merge them :-) JAn Dudík (talk) 22:21, 28 November 2016 (UTC)[reply]
  4.   Support ChristianKl (talk) 16:12, 29 November 2016 (UTC)[reply]
  5.   Support yes Jane023 (talk) 11:04, 30 November 2016 (UTC)[reply]
  6.   Support --Yiyi (talk) 15:51, 3 December 2016 (UTC)[reply]
  7.   Support Richard Nevell (WMUK) (talk) 11:16, 6 December 2016 (UTC)[reply]
  8.   Support Tothasze (talk) 09:35, 7 December 2016 (UTC)[reply]
  9.   Support - DPdH (talk) 10:12, 12 December 2016 (UTC)[reply]

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.

Community discussion

Wikivoyage's listing editor, which integrates Wikidata in a user-friendly way

Voting – Ability to edit Wikidata from WP and other projects

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support --Titou (talk) 08:51, 28 November 2016 (UTC)[reply]
  3.   Support--Gareth (talk) 12:08, 28 November 2016 (UTC)[reply]
  4.   Support Sadads (talk) 15:12, 28 November 2016 (UTC)[reply]
  5.   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)[reply]
  6.   Support Note, this is not for a specific solution.— Jeblad 01:57, 29 November 2016 (UTC)[reply]
  7.   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)[reply]
  8.   Support --Mikey641 (talk) 18:27, 29 November 2016 (UTC)[reply]
  9.   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)[reply]
  10.   Support --Telaneo (User talk page) 22:04, 29 November 2016 (UTC)[reply]
  11.   Support Blue Elf (talk) 00:05, 30 November 2016 (UTC)[reply]
  12.   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)[reply]
  13.   Support Alexei Kopylov (talk) 08:16, 30 November 2016 (UTC)[reply]
  14.   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)[reply]
  15.   Support Trizek from FR 19:59, 30 November 2016 (UTC)[reply]
  16.   Support --Fixuture (talk) 21:20, 30 November 2016 (UTC)[reply]
  17.   Support --Ryan • (talk) • 23:22, 30 November 2016 (UTC)[reply]
  18.   Support --Vachovec1 (talk) 20:51, 1 December 2016 (UTC)[reply]
  19.   Support --FocalPoint (talk) 20:51, 1 December 2016 (UTC)[reply]
  20.   Support Mike Peel (talk) 22:30, 1 December 2016 (UTC)[reply]
  21.   Support --WikedKentaur (talk) 23:22, 1 December 2016 (UTC)[reply]
  22.   SupportPatrug (talk) 00:37, 2 December 2016 (UTC)[reply]
  23.   Support NMaia (talk) 00:43, 2 December 2016 (UTC)[reply]
  24.   Support Libcub (talk) 03:47, 2 December 2016 (UTC)[reply]
  25.   Support --Geraki TL 06:52, 2 December 2016 (UTC)[reply]
  26.   Support Oliv0 (talk) 07:14, 2 December 2016 (UTC)[reply]
  27.   Support Draceane (talk) 11:01, 2 December 2016 (UTC)[reply]
  28.   SupportJc86035 (talk) 11:22, 2 December 2016 (UTC)[reply]
  29.   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)[reply]
  30.   Support --Framawiki (talk) 20:53, 2 December 2016 (UTC)[reply]
  31.   SupportAjraddatz (talk) 23:08, 2 December 2016 (UTC)[reply]
  32.   SupportSusanna Ånäs (Susannaanas) (talk) 11:18, 3 December 2016 (UTC)[reply]
  33.   Support Pamputt (talk) 10:44, 4 December 2016 (UTC)[reply]
  34.   Support --Julien1978 (d.) 12:05, 4 December 2016 (UTC)[reply]
  35.   Support -- T.seppelt (talk) 16:05, 4 December 2016 (UTC)[reply]
  36.   Support --By erdo can • TLK 17:01, 4 December 2016 (UTC)[reply]
  37.   Support--Runner1928 (talk) 02:39, 5 December 2016 (UTC)[reply]
  38.   Support --Epìdosis 20:00, 5 December 2016 (UTC)[reply]
  39.   Support --Kurt Jansson (talk) 22:30, 5 December 2016 (UTC)[reply]
  40.   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)[reply]
  41.   Support--Ranjithsiji (talk) 11:22, 6 December 2016 (UTC)[reply]
  42.   Support Pabouk (talk) 13:08, 6 December 2016 (UTC)[reply]
  43.   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)[reply]
  44.   Support ★ → Airon 90 09:33, 7 December 2016 (UTC)[reply]
  45.   Support --Afernand74 (talk) 11:23, 7 December 2016 (UTC)[reply]
  46.   Support SamanthaNguyen (talk) 03:03, 8 December 2016 (UTC)[reply]
  47.   Support would be very useful --LT910001 (talk) 06:01, 8 December 2016 (UTC)[reply]
  48.   SupportRhododendrites talk \\ 15:00, 8 December 2016 (UTC)[reply]
  49.   Support --Fixer88 (talk) 20:59, 8 December 2016 (UTC)[reply]
  50.   Support --Arnd (talk) 13:52, 9 December 2016 (UTC)[reply]
  51.   Support --Tarjeimo (talk) 23:13, 9 December 2016 (UTC)[reply]
  52.   Support Blue Elf (talk) 23:38, 9 December 2016 (UTC)[reply]
  53.   Support --DangSunM (talk) 01:54, 10 December 2016 (UTC)[reply]
  54.   Support--Nizil Shah (talk) 06:57, 10 December 2016 (UTC)[reply]
  55.   Support--Kaitil (talk) 09:37, 10 December 2016 (UTC)[reply]
  56.   Support --Kjersti Lie (talk) 11:36, 10 December 2016 (UTC)[reply]
  57.   Support --Waldir (talk) 12:11, 10 December 2016 (UTC)[reply]
  58.   Support -- Gabriel Kielland (talk) 13:33, 10 December 2016 (UTC)[reply]
  59.   Support Stigmj (talk) 20:27, 10 December 2016 (UTC)[reply]
  60.   Support This is years overdue.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:31, 11 December 2016 (UTC)[reply]
  61.   Support--Ezzex (talk) 20:14, 11 December 2016 (UTC)[reply]
  62.   Support Ulflarsen (talk) 00:08, 12 December 2016 (UTC)[reply]
  63.   Support no-brainer RadiX 02:27, 12 December 2016 (UTC)[reply]
  64.   Support - DPdH (talk) 10:13, 12 December 2016 (UTC)[reply]
  65.   Support --Elitre (talk) 18:56, 12 December 2016 (UTC)[reply]
  66.   Support --KuboF (talk) 22:34, 12 December 2016 (UTC)[reply]
  67.   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)[reply]
  68.   Support --Yann (talk) 23:52, 12 December 2016 (UTC)[reply]
  69.   Support (disclaimer: I am the initiator) -- Samat (talk) 23:56, 12 December 2016 (UTC)[reply]

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:

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

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

Voting – Ability to reuse references in Wikidata

  1.   Support--Gareth (talk) 12:10, 28 November 2016 (UTC)[reply]
  2.   Support--Aracali (talk) 14:57, 28 November 2016 (UTC)[reply]
  3.   Support Sadads (talk) 15:13, 28 November 2016 (UTC)[reply]
  4.   Support Spinster (talk) 15:44, 29 November 2016 (UTC)[reply]
  5.   Support --YMS (talk) 16:26, 29 November 2016 (UTC)[reply]
  6.   Support ArthurPSmith (talk) 18:52, 29 November 2016 (UTC)[reply]
  7.   Support -- Mushroom (talk) 22:12, 29 November 2016 (UTC)[reply]
  8.   Support Jane023 (talk) 12:27, 30 November 2016 (UTC)[reply]
  9.   Support --Nouill (talk) 14:12, 1 December 2016 (UTC)[reply]
  10.   Support B25es (talk) 17:56, 1 December 2016 (UTC)[reply]
  11.   Support --AmaryllisGardener talk 19:05, 1 December 2016 (UTC)[reply]
  12.   Support Mike Peel (talk) 22:31, 1 December 2016 (UTC)[reply]
  13.   Support Libcub (talk) 03:48, 2 December 2016 (UTC)[reply]
  14.   Support --Geraki TL 06:53, 2 December 2016 (UTC)[reply]
  15.   Support Oliv0 (talk) 07:28, 2 December 2016 (UTC)[reply]
  16.   Support --Entbert (talk) 15:15, 2 December 2016 (UTC)[reply]
  17.   Support I'm also sorely missing a way to reuse a reference on multiple items. - Nikki (talk) 18:22, 2 December 2016 (UTC)[reply]
  18.   Support. Matiia (talk) 23:14, 2 December 2016 (UTC)[reply]
  19.   SupportSusanna Ånäs (Susannaanas) (talk) 11:18, 3 December 2016 (UTC)[reply]
  20.   Support Pamputt (talk) 10:44, 4 December 2016 (UTC)[reply]
  21.   Support -- Marcus Cyron (talk) 12:06, 4 December 2016 (UTC)[reply]
  22.   Support -- the wub "?!" 13:34, 4 December 2016 (UTC)[reply]
  23.   Support --By erdo can • TLK 17:01, 4 December 2016 (UTC)[reply]
  24.   Support --HHill (talk) 10:56, 5 December 2016 (UTC)[reply]
  25.   Support --Bamyers99 (talk) 18:59, 5 December 2016 (UTC)[reply]
  26.   Support Chewbacca2205 (talk) 19:53, 5 December 2016 (UTC)[reply]
  27.   Support --Epìdosis 20:00, 5 December 2016 (UTC)[reply]
  28.   Support Beyond duplicating the references I suppose this means WikiCite collections of all references also. Blue Rasberry (talk) 18:30, 6 December 2016 (UTC)[reply]
  29.   Support Jianhui67 talkcontribs 11:29, 7 December 2016 (UTC)[reply]
  30.   Support --M11rtinb (talk) 16:21, 7 December 2016 (UTC)[reply]
  31.   Support SamanthaNguyen (talk) 03:03, 8 December 2016 (UTC)[reply]
  32.   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)[reply]
  33.   Support This is a no-brainer.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:31, 11 December 2016 (UTC)[reply]
  34.   Support So long I've been waiting for this. RadiX 02:31, 12 December 2016 (UTC)[reply]
  35.   Support - DPdH (talk) 10:14, 12 December 2016 (UTC)[reply]
  36.   Support, although I think a gadget is available for this — NickK (talk) 23:25, 12 December 2016 (UTC)[reply]
  37.   Support --Yann (talk) 23:52, 12 December 2016 (UTC)[reply]

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.
  1. 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:

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)[reply]
    • 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)[reply]
    • I'm not sure whether it would be a good idea. There are two things to consider here:
      1. Roundtrip time (queries can take really long, and I'm not sure putting those in Lua - e.g. callable from parser) is good.
      2. 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)[reply]

Voting – Allow looking up Entities by specific property value

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support --Jarekt (talk) 03:21, 30 November 2016 (UTC)[reply]
  3.   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)[reply]
  4.   Support B25es (talk) 18:02, 1 December 2016 (UTC)[reply]
  5.   Support Libcub (talk) 03:49, 2 December 2016 (UTC)[reply]
  6.   Support --Geraki TL 06:53, 2 December 2016 (UTC)[reply]
  7.   Support -Entbert (talk) 15:16, 2 December 2016 (UTC)[reply]
  8.   Support --Epìdosis 20:01, 5 December 2016 (UTC)[reply]
  9.   Support --Jklamo (talk) 14:41, 9 December 2016 (UTC)[reply]
  10.   Support -- FriedhelmW (talk) 19:06, 9 December 2016 (UTC)[reply]
  11.   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.

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)[reply]
    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)[reply]
    Because up to approx. 800 wikis can be linked with a single Wikidata item. --Vogone (talk) 23:02, 2 December 2016 (UTC)[reply]
    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)[reply]
  • 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)[reply]

Voting – Article history integration

  1.   Support--Gareth (talk) 12:18, 28 November 2016 (UTC)[reply]
  2.   Support ChristianKl (talk) 16:13, 29 November 2016 (UTC)[reply]
  3.   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)[reply]
    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.
  4.   Support Aidera grandement à comprendre ce qui est affiché dans l'article. Pamputt (talk) 07:31, 1 December 2016 (UTC)[reply]
  5.   Support Absolutely necessary. --Tractopelle-jaune (talk) 11:02, 1 December 2016 (UTC)[reply]
  6.   Support NMaia (talk) 00:45, 2 December 2016 (UTC)[reply]
  7.   Support Oliv0 (talk) 07:29, 2 December 2016 (UTC)[reply]
  8.   Support Trizek from FR 13:53, 2 December 2016 (UTC)[reply]
  9.   Support --Cbyd (talk) 12:23, 3 December 2016 (UTC)[reply]
  10.   Support Pamputt (talk) 10:45, 4 December 2016 (UTC)[reply]
  11.   Support. --Julien1978 (d.) 12:00, 4 December 2016 (UTC)[reply]
  12.   Support Psemdel (talk) 19:35, 5 December 2016 (UTC)[reply]
  13.   Support --M11rtinb (talk) 16:21, 7 December 2016 (UTC)[reply]
  14.   Support SamanthaNguyen (talk) 03:02, 8 December 2016 (UTC)[reply]
  15.   Support, of course! Bob Saint Clar (talk) 21:15, 12 December 2016 (UTC)[reply]

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:

Community discussion

Voting – Copy/paste statements of an item

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support --Izno (talk) 01:20, 29 November 2016 (UTC)[reply]
  3.   Support --Melderick (talk) 13:49, 29 November 2016 (UTC)[reply]
  4.   Support -- Stryn (accidentally unsigned)
  5.   Support as proposer, Jane023 (talk) 11:05, 30 November 2016 (UTC)[reply]
  6.   Support Sadads (talk) 15:09, 30 November 2016 (UTC)[reply]
  7.   Support Trizek from FR 20:00, 30 November 2016 (UTC)[reply]
  8.   Support Mike Peel (talk) 22:32, 1 December 2016 (UTC)[reply]
  9.   Support NMaia (talk) 00:45, 2 December 2016 (UTC)[reply]
  10.   Support Libcub (talk) 03:51, 2 December 2016 (UTC)[reply]
  11.   Support --Epìdosis 20:03, 5 December 2016 (UTC)[reply]
  12.   Support Jianhui67 talkcontribs 11:24, 7 December 2016 (UTC)[reply]
  13.   Support SamanthaNguyen (talk) 03:01, 8 December 2016 (UTC)[reply]
  14.   Support Ayack (talk) 12:08, 9 December 2016 (UTC)[reply]
  15.   Support --Jklamo (talk) 14:41, 9 December 2016 (UTC)[reply]
  16.   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).
  • Phabricator tickets: This would be a good demonstration for T76229. Tracked on: T128710

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

Voting – Create infobox for books in Wikipedia

  1.   Support Libcub (talk) 03:52, 2 December 2016 (UTC)[reply]
  2. 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)[reply]

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 datatype form 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 users a 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:

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)[reply]
  • There is a ticket for this at phab:T145532 --Jura1 (talk) 20:33, 20 November 2016 (UTC)[reply]

Voting – Datatype for Hours:Minutes:Seconds

  1.   Support--Wesalius (talk) 08:19, 28 November 2016 (UTC)[reply]
  2.   Support SamanthaNguyen (talk) 22:31, 28 November 2016 (UTC)[reply]
  3.   Support ChristianKl (talk) 16:05, 29 November 2016 (UTC)[reply]
  4.   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)[reply]
  5.   Support definitely needed ArthurPSmith (talk) 17:36, 29 November 2016 (UTC)[reply]
  6.   Support --Mikey641 (talk) 18:21, 29 November 2016 (UTC)[reply]
  7.   Oppose Let'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)[reply]
    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)[reply]
    Now that the proposal has been ammended, I'm   Neutral about it. Matěj Suchánek (talk) 21:24, 11 December 2016 (UTC)[reply]
  8.   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)[reply]
    @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)[reply]
    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)[reply]
  9.   Support Libcub (talk) 03:55, 2 December 2016 (UTC)[reply]
  10.   Oppose new datatype, I would support improving the user interface for the existing data. Multichill (talk) 14:15, 2 December 2016 (UTC)[reply]
  11.   Oppose Like Multichill --β16 - (talk) 11:52, 5 December 2016 (UTC)[reply]
    @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)[reply]
    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)[reply]
  12.   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)[reply]
      Support Now that the proposal has been ammended I agree with it. Barcex (talk) 18:25, 10 December 2016 (UTC)[reply]
  13.   Oppose Confuses data and presentation. Glrx (talk) 03:04, 9 December 2016 (UTC)[reply]
    @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)[reply]
  14.   Support - DPdH (talk) 10:16, 12 December 2016 (UTC)[reply]

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:

Community discussion


Voting – Easily duplicate parts of an item

  1.   Support--Gareth (talk) 12:15, 28 November 2016 (UTC)[reply]
  2.   Support ChristianKl (talk) 16:06, 29 November 2016 (UTC)[reply]
  3.   Support --YMS (talk) 16:21, 29 November 2016 (UTC)[reply]
  4.   Support as proposer, Jane023 (talk) 12:30, 30 November 2016 (UTC)[reply]
  5.   Support Libcub (talk) 03:56, 2 December 2016 (UTC)[reply]
  6.   Support --Epìdosis 20:04, 5 December 2016 (UTC)[reply]
  7.   Support --Ambre Troizat (talk) 11:05, 8 December 2016 (UTC)[reply]
  8.   Support --Jklamo (talk) 14:41, 9 December 2016 (UTC)[reply]

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

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

Voting – Easy inter-project linking

  1.   Support as proposer Ninovolador (talk) 11:38, 28 November 2016 (UTC)[reply]
  2.   Support JAn Dudík (talk) 22:17, 28 November 2016 (UTC)[reply]
  3.   Support -- Gareth (talk) 02:45, 29 November 2016 (UTC)[reply]
  4.   SupportStevenJ81 (talk) 16:59, 29 November 2016 (UTC)[reply]
  5.   Support --Mikey641 (talk) 18:21, 29 November 2016 (UTC)[reply]
  6.   Support Alexei Kopylov (talk) 08:12, 30 November 2016 (UTC)[reply]
  7.   Support NMaia (talk) 00:47, 2 December 2016 (UTC)[reply]
  8.   Support Libcub (talk) 03:57, 2 December 2016 (UTC)[reply]
  9.   Support --Epìdosis 20:05, 5 December 2016 (UTC)[reply]
  10.   Support --Ambre Troizat (talk) 11:06, 8 December 2016 (UTC)[reply]
  11.   Support MechQuester (talk) 05:43, 9 December 2016 (UTC)[reply]
  12.   Support --KuboF (talk) 22:42, 12 December 2016 (UTC)[reply]
  13.   Support, linking pages in Wikipedia and Wikisource or Wikinews in the same language should be easier — NickK (talk) 23:29, 12 December 2016 (UTC)[reply]
  14.   Support --Yann (talk) 23:54, 12 December 2016 (UTC)[reply]

Improve QuickStatements