Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Wikidata

< Community Wishlist Survey 2016
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

none

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 Ukraine — NickK (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 query.wikidata.org 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.   Support —Jc86035 (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 talk★contribs 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)❤T☮C☺M☯ 19:45, 2 December 2016 (UTC)[reply]
  20.   Support --Framawiki (talk) 20:52, 2 December 2016 (UTC)[reply]
  21.   Support – Ajraddatz (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 talk★contribs 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.   Support —DerHexer (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.   Support — NickK (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.   Support —Patrug (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.   Support —Jc86035 (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.   Support – Ajraddatz (talk) 23:08, 2 December 2016 (UTC)[reply]
  32.   Support – Susanna Å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.   Support — Rhododendrites 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.   Support – Susanna Å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 talk★contribs 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 talk★contribs 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

none

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.   Support — StevenJ81 (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

  • 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
  • Phabricator tickets:

Community discussion

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

Voting – Improve QuickStatements

  1.   Support--Wesalius (talk) 08:19, 28 November 2016 (UTC)[reply]
  2.   Support ChristianKl (talk) 16:06, 29 November 2016 (UTC)[reply]
  3.   Support --ValterVB (talk) 18:03, 29 November 2016 (UTC)[reply]
  4.   Support -- Mushroom (talk) 22:14, 29 November 2016 (UTC)[reply]
  5.   Support --Jarekt (talk) 03:06, 30 November 2016 (UTC)[reply]
  6.   Support Syced (talk) 07:13, 30 November 2016 (UTC)[reply]
  7.   Support --Jklamo (talk) 15:00, 30 November 2016 (UTC)[reply]
  8.   Support Sadads (talk) 15:07, 30 November 2016 (UTC)[reply]
  9. 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)[reply]
  10.   Support --Beat Estermann (talk) 09:21, 1 December 2016 (UTC)[reply]
  11.   Support Libcub (talk) 03:58, 2 December 2016 (UTC)[reply]
  12.   Support —Jc86035 (talk) 11:22, 2 December 2016 (UTC)[reply]
  13.   Support --Mr. Ibrahem (talk) 12:28, 2 December 2016 (UTC)[reply]
  14.   Support--Runner1928 (talk) 02:41, 5 December 2016 (UTC)[reply]
  15.   Support --β16 - (talk) 11:54, 5 December 2016 (UTC)[reply]
  16.   Support --Epìdosis 20:06, 5 December 2016 (UTC)[reply]
  17.   Support Jianhui67 talk★contribs 11:25, 7 December 2016 (UTC)[reply]
  18.   Support --Arnd (talk) 13:49, 9 December 2016 (UTC)[reply]
  19.   Support --NaBUru38 (talk)

Improved watchlist integration

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

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

  • @Oliv0: phab:T90435 has a huge list of subtasks. Which of those would you most want us to focus on? Ryan Kaldari (WMF) (talk) 00:25, 23 November 2016 (UTC)[reply]
    I have put focus above on the first point of the description of phab:T90435: "avoid showing changes to connected item(s) that do not affect the local page (labels in other languages, etc)". Among the long list of technical tasks attached, most are less important points like appearance, but some may indeed be necessary technicalities for a better choice of the Wikidata edits displayed in the watchlist. At first sight phab:T90436 "Improve usage tracking granularity to avoid irrelevant changes showing in the watchlist" is the task that I would most like devs to focus on. Oliv0 (talk) 08:01, 23 November 2016 (UTC)[reply]
  • Probably this has already been discussed, yet I'd like to insist on one point : I'm scared at the huge facility for vandalism on Wikidata, even if most vandals have not yet discovered it. Any improvement that would allow contributors to get awared of Wikidata-driven changes on pages they watch is highly wellcome. --Ariel Provost (talk) 07:50, 1 December 2016 (UTC)[reply]

I have about 10,000 pages on my watchlist. I tried for about one year to include Wikidata in it, but I have thrown in the towel : there was too much unrelated elements in my watchlist. The main problem is that the inclusion of Wikidata changes in my watchlist included changes not only about the linked element, but also about the properties of the followed element. As a result, you see the changes of that property for a lot of pages of your watchlist who include it. This flooding is bad. It make my watchlist ineffective by exploding it and drowning my attention (Ça explose systématiquement la limite de changements affichables de ma liste de suivi et noie les changements à surveiller parmi des changements non pertinents. La raison d'être de ma liste de suivi est conséquemment totalement évacuée.)Simon Villeneuve 12:09, 4 December 2016 (UTC)

Voting – Improved watchlist integration

  1.   Support JAn Dudík (talk) 22:18, 28 November 2016 (UTC)[reply]
  2.   Support --YMS (talk) 16:22, 29 November 2016 (UTC)[reply]
  3.   Support Trizek from FR 19:57, 30 November 2016 (UTC)[reply]
  4.   Support Pamputt (talk) 07:32, 1 December 2016 (UTC)[reply]
  5.   Support -- Ariel Provost (talk) 07:50, 1 December 2016 (UTC)[reply]
  6.   Support -- AvatarFR (talk) 09:39, 1 December 2016 (UTC)[reply]
  7.   Support Absolutely necessary for the watchlist grouped. --Tractopelle-jaune (talk) 11:05, 1 December 2016 (UTC)[reply]
  8.   Support ChristianKl (talk) 11:21, 1 December 2016 (UTC)[reply]
  9.   Support Libcub (talk) 04:00, 2 December 2016 (UTC)[reply]
  10.   Support Oliv0 (talk) 07:36, 2 December 2016 (UTC)[reply]
  11.   Support --Cbyd (talk) 12:24, 3 December 2016 (UTC)[reply]
  12.   Support. --Julien1978 (d.) 12:10, 4 December 2016 (UTC)[reply]
  13.   Support Simon Villeneuve 12:14, 4 December 2016 (UTC)
  14.   Support MGChecker (talk) 13:17, 4 December 2016 (UTC)[reply]
  15.   Support --By erdo can • TLK 17:02, 4 December 2016 (UTC)[reply]
  16.   Support --Epìdosis 20:06, 5 December 2016 (UTC)[reply]
  17.   Support Jianhui67 talk★contribs 11:25, 7 December 2016 (UTC)[reply]
  18.   Support O.Taris (discuter) 21:15, 11 December 2016 (UTC)[reply]
  19.   Support, of course! Bob Saint Clar (talk) 21:14, 12 December 2016 (UTC)[reply]

Keep Wikidata in sync with external databases

  • Problem: Importing data with a one-time procedure is good, but we should think about what happens afterwards: we have to keep the data in sync. Many people import from external information sources (Examples: museum web page listing the birth/death of Sri Lanka singers, foreign affairs website listing Luxemburg's embassies, etc) using a self-made combination of scripts+spreadsheets+copy/pasting, then input the results in QuickStatements or similar APIs. Then they forget about it, the scripts stay on their own computers and eventually get deleted, and the next person who wants to update the info from the same website has to start from scratch, and figure out what items have to be created and what items have to be updated and how.
  • Who would benefit: People who import specialized datasets into Wikidata
  • Proposed solution: Let's have a platform that facilitates reuse and keeps the data in sync. Rationalize the process, make it less error-prone, more efficient, and more collaborative, by having a Git-backed webapp where people can easily:
    • Propose a new import script (including metadata about copyright) via a pull request. An import script scrapes information from some website and generates a QuickStatements file.
    • Run an existing import script, potentially with a preview screen to check that data has been correctly extracted before injecting it into Wikidata.
    • Metadata is kept about when the data was last synchronized, and when each data element has been updated last, both on the external side and on the Wikidata side.
    • Metadata is kept about exceptions (cases where the external database is wrong, for instance).

All of these modules (except the import scripts) would be the same for all databases, which would help a lot in factorizing efforts, avoiding traps, making sync efficient, preventing contributors from overwriting each other endlessly.

  • Phabricator tickets:

Community discussion

  • I wonder how many people doing this sort of updating are doing it from a system that supports the Protocol for Metadata Harvesting? That's one common system of regularly pulling in metadata. Would be a great GLAM selling point if we could automate this sort of thing. It would also be easier than supporting ad-hoc scripting… :) Sam Wilson 06:20, 15 November 2016 (UTC)[reply]
I love OAI-PMH, and it is unfortunate that most external database do not implement it. Most databases are very low-tech: HTML bullet lists, CSV file on an FTP server, etc. As an example, emergency evacuation centers in Japan are defined by the government in data tables in PDF files linked from its homepage and updated once in a while. Syced (talk) 07:54, 15 November 2016 (UTC)[reply]
Very true. Still, it would be extremely useful if we would adopt existing, open standards ourselves, even if not many websites support this (yet). Our adoption might be a catalyst/encouragement for others to adopt it too. Spinster (talk) 20:18, 15 November 2016 (UTC)[reply]
I reckon working with open standards is a good thing, and it's also a lot easier than supporting multiple poorly-defined (or web-scraped) interfaces. :-) I'd rather help GLAMs use e.g. AtoM than build a tool that only works for one project. No, I mean firstly, actually: that we support open standards first and then move on to other set-ups. Sam Wilson 05:26, 18 November 2016 (UTC)[reply]
Yes, such tools are a good image for the extraction part, though I guess many people will just write their own scripts. A problem with the tools you mentioned is that they cost money. Cheers! Syced (talk) 03:59, 18 November 2016 (UTC)[reply]

Voting – Keep Wikidata in sync with external databases

  1.   Support--Wesalius (talk) 08:19, 28 November 2016 (UTC)[reply]
  2.   Support -- it would be really good to have a backlog tool, that notes that the source for a particular data point has changed the data -- this would also be really important for commons:Commons:Structured Commons, Sadads (talk) 15:08, 28 November 2016 (UTC)[reply]
  3.   Support MichaelMaggs (talk) 20:29, 28 November 2016 (UTC)[reply]
  4.   Support JSONstat for statistics! — Jeblad 01:59, 29 November 2016 (UTC)[reply]
  5.   Support Crucial functionality to keep Wikidata alive, healthy and kicking. Spinster (talk) 15:34, 29 November 2016 (UTC)[reply]
  6.   Support this is a great idea though the proposal is not really detailed enough to say how it would work in practice. But something like this is needed. Don't forget Mix n Match as an import/sync tool also... ArthurPSmith (talk) 17:41, 29 November 2016 (UTC)[reply]
  7.   Support -- Mushroom (talk) 22:15, 29 November 2016 (UTC)[reply]
  8.   Support It would be also nice to keep it in synch with other Wiki projects. For example there are several properties listing pages on commons which are not altered when pages are deleted or renamed. --Jarekt (talk) 03:10, 30 November 2016 (UTC)[reply]
  9.   Support Syced (talk) 07:13, 30 November 2016 (UTC)[reply]
  10.   Support Important functionality to make Wikidata scale in the long term and play its role of a big data hub connecting many other databases. --Beat Estermann (talk) 09:10, 1 December 2016 (UTC)[reply]
  11.   Support Ainali (talk) 11:16, 1 December 2016 (UTC)[reply]
  12.   Support Jsamwrites (talk) 18:35, 1 December 2016 (UTC)[reply]
  13.   Support Mike Peel (talk) 22:35, 1 December 2016 (UTC)[reply]
  14.   Support Libcub (talk) 04:02, 2 December 2016 (UTC)[reply]
  15.   Support Oliv0 (talk) 07:39, 2 December 2016 (UTC)[reply]
  16.   Support —Jc86035 (talk) 11:22, 2 December 2016 (UTC)[reply]
  17.   Support --Sabas88 (talk) 11:07, 3 December 2016 (UTC)[reply]
  18.   Support Strakhov (talk) 16:21, 3 December 2016 (UTC)[reply]
  19.   Support Mike Linksvayer (talk) 05:00, 4 December 2016 (UTC)[reply]
  20.   Support --By erdo can • TLK 17:02, 4 December 2016 (UTC)[reply]
  21.   Support--Runner1928 (talk) 02:41, 5 December 2016 (UTC)[reply]
  22.   Support --HHill (talk) 10:58, 5 December 2016 (UTC)[reply]
  23.   Support --β16 - (talk) 11:55, 5 December 2016 (UTC)[reply]
  24.   Support --Epìdosis 20:07, 5 December 2016 (UTC)[reply]
  25.   Support Richard Nevell (WMUK) (talk) 11:04, 6 December 2016 (UTC)[reply]
  26.   Support Pabouk (talk) 13:11, 6 December 2016 (UTC)[reply]
  27.   Support--Afernand74 (talk) 09:22, 7 December 2016 (UTC)[reply]
  28.   Support Jianhui67 talk★contribs 11:26, 7 December 2016 (UTC)[reply]
  29.   Support This one's definitely needed. --Fixer88 (talk) 20:57, 8 December 2016 (UTC)[reply]
  30.   Support LeadSongDog (talk) 04:48, 9 December 2016 (UTC)[reply]
  31.   Support Opabinia regalis (talk) 06:52, 9 December 2016 (UTC)[reply]
  32.   Support Smb1001 (talk) 15:24, 9 December 2016 (UTC)[reply]
  33.   Support --DangSunM (talk) 01:43, 10 December 2016 (UTC)[reply]
  34.   Support--Nizil Shah (talk) 06:29, 10 December 2016 (UTC)[reply]
  35.   Support --Chrumps (talk) 03:21, 11 December 2016 (UTC)[reply]
  36.   Support  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:32, 11 December 2016 (UTC)[reply]
  37.   Support - DPdH (talk) 10:17, 12 December 2016 (UTC)[reply]
  38.   Support — NickK (talk) 23:29, 12 December 2016 (UTC)[reply]

Let Wikidata be more useful for Big Data

  • Problem: Queries on the WikiData Query Service can provide great insights, but if you try to retrieve too much data, or try to do too much with it, you get a "Query timeout limit reached" error and no data returned (especially with graphs).
  • Who would benefit: People who want to actually use the data, not just store it. People who can't write super-efficient code (like me).
  • Proposed solution: Allow longer timeouts. Show partial results. Guide the user as to why it timed out. Which part of the query code was expensive/took the longest? Be more user friendly? (the example queries are great, the manual is OK, but it is so hard to learn how to write your own queries, but that's another issue).
  • More comments: I assume that it may be server load related? Can it be dynamic? Can users be allocated a amount of server time before being limited? Is the query service used that often that it needs to be limited? Or am I just writing really bad code? (highly likely as I'm not a trained coder and am just copying/modifying other examples, but you shouldn't be forcing everyone who wants to try to use WikiData to be a master coder)
  • Phabricator tickets:

Community discussion

Given that server time isn't free it might be worthwhile to sell subscription to the query tool that allow for much longer timeouts. ChristianKl (talk) 10:12, 17 November 2016 (UTC)[reply]

Indeed. Companies willing to use Wikidata for critical applications would probably be willing to pay to get better SLA. Syced (talk) 07:49, 21 November 2016 (UTC)[reply]

Another solution could be some authentication and allowing higher limits just to particular users. It could be admins in any wiki, users with more than N edits without bot flag (or on contrary with bot flag), or users who will get personal access green light by some request for permission page. --Base (talk) 14:57, 28 November 2016 (UTC)[reply]

Voting – Let WikiData be more useful for Big Data

  1.   Support--Wesalius (talk) 08:19, 28 November 2016 (UTC)[reply]
  2.   Strong support --Base (talk) 14:46, 28 November 2016 (UTC)[reply]
  3.   Support Spinster (talk) 15:35, 29 November 2016 (UTC)[reply]
  4.   Support --YMS (talk) 16:22, 29 November 2016 (UTC)[reply]
  5.   Support -- Mushroom (talk) 22:15, 29 November 2016 (UTC)[reply]
  6.   Support I have only wrote one or two Wikidata queries and spend most of my time trying to decipher why it is timing out. Got it to work but never figure out why was it slow. Some postmortem way to profile the query would be great. --Jarekt (talk) 03:16, 30 November 2016 (UTC)[reply]
  7.   Support --Jklamo (talk) 15:01, 30 November 2016 (UTC)[reply]
  8.   Support Several avenues to achieve this should be explored. --Beat Estermann (talk) 09:11, 1 December 2016 (UTC)[reply]
  9.   Support Libcub (talk) 04:02, 2 December 2016 (UTC)[reply]
  10.   Support --Epìdosis 20:08, 5 December 2016 (UTC)[reply]
  11.   Support Nev1 (talk) 11:06, 6 December 2016 (UTC)[reply]
  12.   Support --M11rtinb (talk) 16:16, 7 December 2016 (UTC)[reply]
  13.   Support --Fixer88 (talk) 20:57, 8 December 2016 (UTC)[reply]

Make search suggestions work for pages outside the main namespace

  • Problem: The search suggestions box does not give suggestions for pages outside the main namespace. This makes it difficult to find other pages than items.
  • Who would benefit: All users.
  • Proposed solution: (by user Beta16)

A possible solution can be to add a 'hamburger menu' (or other of similar) next to the search box. When open, this new menu will show two options (radio button: only one can be selected):

  • Search only among Wikidata items
  • Search in non-main namespaces

The first choice is the default selected.

Community discussion

  • There was a gadget that used to work quite well. I have no idea why the search was made so complicated. Nemo 08:38, 15 November 2016 (UTC)[reply]
  • Yes. Not being able to find existing properties is the main inconvenience. --Jura1 (talk) 20:35, 20 November 2016 (UTC)[reply]
  • @XXN: One reason that suggestions are limited to mainspace is that there are lots of pages there with labels that begin with namespace names. So, for example, if you want to quickly jump to Help:Contents, the search suggestion would have to present both the Wikidata help page and the Q914807 item that represents the concept of a MediaWiki help page. Whereas on a 'normal' wiki, it isn't possible to have such duplication of page titles. I'm not sure how hard it would be to implement search suggestions across all namespaces, but would a worthwhile minimal version of this proposal be to just enable additional search suggestions in the 'Property' namespace? There would be no name collisions then. —SWilson (WMF) (talk) 06:00, 23 November 2016 (UTC)[reply]

Voting – Make search suggestions work for pages outside the main namespace

  1.   Support--Wesalius (talk) 08:19, 28 November 2016 (UTC)[reply]
  2.   Support-- Gareth (talk) 11:58, 28 November 2016 (UTC)[reply]
  3.   Support, I think it should not be too hard to implement. --Stryn (talk) 12:50, 28 November 2016 (UTC)[reply]
  4.   Support --Micru (talk) 13:29, 28 November 2016 (UTC)[reply]
  5.   Support. Max Semenik (talk) 20:23, 28 November 2016 (UTC)[reply]
  6.   Support This has been annoying me since I became active on Wikidata. Matěj Suchánek (talk) 21:50, 28 November 2016 (UTC)[reply]
  7.   Support JAn Dudík (talk) 22:20, 28 November 2016 (UTC)[reply]
  8.   Support --Mikey641 (talk) 18:22, 29 November 2016 (UTC)[reply]
  9.   Support -- Mushroom (talk) 22:16, 29 November 2016 (UTC)[reply]
  10.   Support -- Jc3s5h (talk) 23:33, 29 November 2016 (UTC)[reply]
  11.   Support --Jklamo (talk) 15:02, 30 November 2016 (UTC)[reply]
  12.   Support --AmaryllisGardener talk 19:00, 1 December 2016 (UTC)[reply]
  13.   Support NMaia (talk) 00:26, 2 December 2016 (UTC)[reply]
  14.   Support Orgio89 (talk) 02:34, 2 December 2016 (UTC)[reply]
  15.   Support —Jc86035 (talk) 11:22, 2 December 2016 (UTC)[reply]
  16.   Support MGChecker (talk) 13:17, 4 December 2016 (UTC)[reply]
  17.   Support T.seppelt (talk) 16:07, 4 December 2016 (UTC)[reply]
  18.   Support--Runner1928 (talk) 02:42, 5 December 2016 (UTC)[reply]
  19.   Support of course :) --β16 - (talk) 11:58, 5 December 2016 (UTC)[reply]
  20.   Support --Epìdosis 20:08, 5 December 2016 (UTC)[reply]
  21.   Support Richard Nevell (WMUK) (talk) 11:10, 6 December 2016 (UTC)[reply]
  22.   Support Jianhui67 talk★contribs 11:26, 7 December 2016 (UTC)[reply]
  23.   Support --FocalPoint (talk) 21:57, 7 December 2016 (UTC)[reply]
  24.   Support Ayack (talk) 12:09, 9 December 2016 (UTC)[reply]
  25.   Support --DangSunM (talk) 01:53, 10 December 2016 (UTC)[reply]
  26.   Oppose, as the usefulness of those results would be worse. --NaBUru38 (talk) 21:52, 10 December 2016 (UTC)[reply]
  27.   Support --Yann (talk) 23:55, 12 December 2016 (UTC)[reply]

Making Wikidata editable for human beings

  • Problem: Editing in Wikidata is much different from editing Wikipedia, as the user interface is a wall which seperates the editor from the data, and, depending on individual settings, hides some of the data within an item. So editing takes much time, is difficult to learn, and reverting vandalism is nearly impossible.
  • Who would benefit: Every editor who is not a bot, but a human being.
  • Proposed solution: The whole data have to be transferred into a transparent format, so that every item consists of a text file like Wikipedia articles do. When saving an edit, an automatic syntax check has to be made, which gives hints, for example, where brackets are missing.

Interwiki links should look like they were on wikipedia, for example:


[[de:P. Shiv Shankar]]
[[en:P. Shiv Shankar]]
[[ml:പി. ശിവശങ്കർ]]

Statements should be made within 2 different kinds of templates: Fix templates in which a fixed number of lines can be filled in or left blank, but must not be deleted:


{{Template:Person
|name = Punjala Shiv Shankar
|birth_date = 1929.08.10
|death_date =
|sex = male
}}

open templates, with a flexible number of lines, could work like:


{{Template political function
|Q8497090 Governor of Kerala = 1995.11.12 to 1996.05.01
|Q8497300 Governor of Sikkim = 1994.09.21 to 1995.11.11
}}

  • Phabricator tickets:

Community discussion

  • I like the idea given that it would make it easier to automate a lot of editing tasks. ChristianKl (talk) 22:26, 19 November 2016 (UTC)[reply]
  • As an advocate of data literacy I'd like to stress that teaching wikidata is like teaching a almost totally new wiki, and that's boring, but once they've learned people are much more self-sufficient than on a local wikipedia. This is what has happened so far in my experience with it-N users... If they want to learn, they learn much faster than on their local wikipedia, complexity is not so big.. Approx. 10% of them enjoy the new platform, and they do in the end a terrific job. The linear (sometimes simple) tasks of wikidata can be handled in the end by a limited but motivated workforce on their area of interest (my test was and is done on local geography items, for example). That's my experience. There are also smaller improvements that might help in any case. I would suggest a real discussion about wikidata and "wikidata-newbies", some sort of survey during the following year, and than based on the feedback decide if the most urgent request is a new type of interface or some other type of approach (targeting potentially motivated new editors I'm sure it's possible too). Just to be clear: I am not again this proposal, on the contrary, but I would really like to see some accurate planning here. Wikidata has a strong impact on many local wiki, we have to be cautious and use accurate method when possible, IMHO, or we'll never build a good (namely balanced) community, in the end.Also, the dismantling of the human-geared autopatrolled flag on wikidata was IMHO a mistake in this early years, it should have helped to filter users on the long term in a much more effective way, and correct critical behaviors in a more targeted way too. --Alexmar983 (talk) 04:47, 20 November 2016 (UTC)[reply]
    • Maybe it could be possible to make both modes of editing available once the data have been transferred into a text file, so that those who like the user interface still can use it? This could also be useful for those who use the user interface in a non-latin script (Arabic, Korean, Chinese...) and would have difficulties editing a text file which would be in English. Of course, if this proposal becomes accepted, there should be a broad discussion about how the syntax of the text file should be, to make it optimally readable and editable for human beings and also for bots. -- Aspiriniks (talk) 08:17, 20 November 2016 (UTC)[reply]
Aspiriniks have you seen the proposal about a better integration with local project (sort of a VE for wikidata from local platform, if I remember correctly)? It's called Wikidata integration in Wikipedia (and other projects)--Alexmar983 (talk) 11:51, 21 November 2016 (UTC)[reply]

Now Wikidata is almost uneditable from any not very great comptuter. All those Javascripts needed to edit it consume so many resources that even my old 4Gb RAM laptop struggles, something like my university library 512Mb RAM Windows XP PCs are just not made to work with it. Some textual mode, though the solution is strange but deserves to be considered seriously, would help the problem and enable editing from any device. --Base (talk) 15:08, 28 November 2016 (UTC)[reply]

Voting – Making Wikidata editable for human beings

  1.   Oppose I really don't undestand what roadblocks prevent "human beings" from editing Wikidata. Showing its data in a wikitext-like format would be just a step backwards. Matěj Suchánek (talk) 17:06, 29 November 2016 (UTC)[reply]
  2.   Oppose I think that wikidata is really nice to use --Mikey641 (talk) 18:24, 29 November 2016 (UTC)[reply]
  3.   Oppose the way this is presented. Doing Wikidata in wikitext is a bad idea. I support making it more easy and intuitive in general, but this is the wrong way to go about it. --Telaneo (User talk page) 22:03, 29 November 2016 (UTC)[reply]
  4.   Oppose In the background, wikidata data is just JSON. Having a converter from JSON to Wikidata is feasible, but the other way around would be a nightmare.--Strainu (talk) 10:01, 30 November 2016 (UTC)[reply]
  5.   Oppose Of course there are lots of people who feel confused and worried about Wikidata (this also happened when Wikimedia Commons was introduced). In order to avoid having messes that need to be cleaned up later, I oppose offloading any editing of Wikidata to Wikipedia projects. I find it upsetting that all illustrators of non-English Wikipedia articles *must* upload to Commons (often making big messes in the beginning), but I agree that it's easier to find people to clean up those Commons messes rather than have separate unconnected image repositories. The same is true for metadata on Wikidata. Jane023 (talk) 10:31, 30 November 2016 (UTC)[reply]
  6.   Oppose Make a thorough analysis first what the problem is really about; experiment with different solutions to solving/diminishing the problem. I don't think the suggested solution would lead us in the right direction. --Beat Estermann (talk) 09:15, 1 December 2016 (UTC)[reply]
  7.   Support Libcub (talk) 03:05, 2 December 2016 (UTC)[reply]
  8.   Oppose I was surprised to read this proposal! I think Wikidata is very easy to edit by hand (and I'm a human...) --Egon Willighagen (talk) 07:09, 2 December 2016 (UTC)[reply]
  9.   Oppose It's true that editing Wikidata it's much different from editing Wikipedia, but it's very easy to learn and it's very intuitive. I think it's much easy like it's now that if it was like editing a text file. --Jordi G (talk) 09:02, 2 December 2016 (UTC)[reply]
  10.   Oppose editing Wikidata is easier than editing wikitext. Multichill (talk) 14:12, 2 December 2016 (UTC)[reply]
  11.   Support As stated above, the possibility to use the user interface would not be abolished, but an additional possibility would be created. Of course, wikidata is easy to learn, but the operator convenience is still extremely bad and there simply is no necessity to learn operating this user interface, when editing in a wikitext is much faster and easier for those who learned that. -- Aspiriniks (talk) 09:05, 4 December 2016 (UTC)[reply]
  12.   Support -- Marcus Cyron (talk) 12:04, 4 December 2016 (UTC)[reply]
  13.   Oppose -- T.seppelt (talk) 16:09, 4 December 2016 (UTC)[reply]
  14.   Oppose --Rschen7754 04:44, 5 December 2016 (UTC)[reply]
  15.   Oppose A complete step backwards. Making things more like the typical wiki interface will absolutely not make it easier for new people to edit data. – Ajraddatz (talk) 05:12, 5 December 2016 (UTC)[reply]
  16.   Oppose If this were to be implemented as suggested, there would now be several methods of e.g. adding a birthday to an item. Not only is this confusing, but how should the Wikidata software know how to generate the "Wikitext" from the database? Which "template" would be used as the default?--Cirdan (talk) 19:02, 5 December 2016 (UTC)[reply]
  17.   Oppose I am not a human (but IT guy) so I understand the statement, that Wikidata are hard to edit for [occasional] human editors. But as my colleges said, using wikitext for Wikidata wouldn't bw right step. --KuboF (talk) 22:59, 12 December 2016 (UTC)[reply]

Mobile UI for Wikidata

  • Problem: WIkidata is a pain to use on mobile
  • Who would benefit: Editors of Wikidata using a mobile interface; anyone benefitting from the data they entered
  • Proposed solution: Improve the editing so it actually works on mobile
  • Phabricator tickets:

Community discussion

  • I think Wikidata is the most suitable project to be on mobile. It can be easily edited as one does not need to write long sentences. It can be big push for it. I also propose a standalone app for it too.-Nizil Shah (talk) 02:07, 11 November 2016 (UTC)[reply]

Voting – Mobile UI for Wikidata

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support--Gareth (talk) 12:00, 28 November 2016 (UTC)[reply]
  3.   Support Sadads (talk) 15:09, 28 November 2016 (UTC)[reply]
  4.   Support --Micru (talk) 16:07, 28 November 2016 (UTC)[reply]
  5.   Support JAn Dudík (talk) 22:20, 28 November 2016 (UTC)[reply]
  6.   Support though I am not using mobile versions of any other site --YMS (talk) 16:23, 29 November 2016 (UTC)[reply]
  7.   Support Matěj Suchánek (talk) 17:05, 29 November 2016 (UTC)[reply]
  8.   Support --Mikey641 (talk) 18:24, 29 November 2016 (UTC)[reply]
  9.   Support -- Mushroom (talk) 22:06, 29 November 2016 (UTC)[reply]
  10.   Support --AmaryllisGardener talk 19:01, 1 December 2016 (UTC)[reply]
  11.   Support Wikidata is *the* most suitable Wikimedia project for editing on a mobile, making this easier to do makes complete sense. Thanks. Mike Peel (talk) 22:22, 1 December 2016 (UTC)[reply]
  12.   Support – Fayenatic london (talk) 22:43, 1 December 2016 (UTC)[reply]
  13.   Support SamanthaNguyen (talk) 22:57, 1 December 2016 (UTC)[reply]
  14.   Support NMaia (talk) 00:27, 2 December 2016 (UTC)[reply]
  15.   Support Libcub (talk) 03:05, 2 December 2016 (UTC)[reply]
  16.   Support —Jc86035 (talk) 11:22, 2 December 2016 (UTC)[reply]
  17.   Support --Adert (talk) 22:45, 2 December 2016 (UTC)[reply]
  18.   Support -- the wub "?!" 13:40, 4 December 2016 (UTC)[reply]
  19.   Support T.seppelt (talk) 16:09, 4 December 2016 (UTC)[reply]
  20.   Support--Runner1928 (talk) 02:43, 5 December 2016 (UTC)[reply]
  21.   Support --HHill (talk) 10:59, 5 December 2016 (UTC)[reply]
  22.   Support --Almondega (talk) 11:11, 6 December 2016 (UTC)[reply]
  23.   Support Richard Nevell (WMUK) (talk) 11:13, 6 December 2016 (UTC)[reply]
  24.   Support ★ → Airon 90 09:28, 7 December 2016 (UTC)[reply]
  25.   Support Jianhui67 talk★contribs 11:27, 7 December 2016 (UTC)[reply]
  26.   Support --M11rtinb (talk) 16:19, 7 December 2016 (UTC)[reply]
  27.   Support Barcex (talk) 19:46, 8 December 2016 (UTC)[reply]
  28.   Support --Arnd (talk) 13:49, 9 December 2016 (UTC)[reply]
  29.   Support --DangSunM (talk) 01:53, 10 December 2016 (UTC)[reply]
  30.   Support--Nizil Shah (talk) 06:57, 10 December 2016 (UTC)[reply]
  31.   Support Giorgos ab1234 (talk) 13:08, 11 December 2016 (UTC)[reply]
  32.   Support - DPdH (talk) 10:18, 12 December 2016 (UTC)[reply]
  33.   Support --Infovarius (talk) 11:28, 12 December 2016 (UTC)[reply]
  34.   Support --Malyacko (talk) 18:46, 12 December 2016 (UTC)[reply]
  35.   Support --KuboF (talk) 23:08, 12 December 2016 (UTC)[reply]
  36.   Support, I was quite annoyed by various bugs when I tried to edit Wikidata on mobile lately — NickK (talk) 23:31, 12 December 2016 (UTC)[reply]

More database functions: i.e. WP-Categories as Select-Statements

  • Problem: There is a lot of manual and erratic editing on categories in the interwikis. Why do we have wikidata? Almost all of the content referenced to categories could be generated from wikidata properties. In a database-oriented manner this would be a simple select-statement. I do not know how the wikidata attributes are saved on the servers but it would be quite dumb not to store them in a relational database approach. I do not believe that there should be many technical obstacles. In opposite it seems that there is a lot of wikidata properties and content generated from manually edited categories. Is there a citation needed to edit categories? This approach is wrong. It should be the other way around.
  • Who would benefit: Editors in the interwikis: Better handling of categories through standard selections from wikidata. Data storage: Most of the Wikidata properties and wikipedia categories are the same information in a different way. So information is stored redundantly and inconsistently.
  • Proposed solution: Replace this rattail of categories in articles with generated properties from wikidata. Replace the category lemmata with select-statements from the wikidata database.
  • Phabricator tickets:

Community discussion

It sounds like you are not familiar with existing tools that already essentially do what you are asking? For example Template:Wikidata list is available in English wikipedia. ArthurPSmith (talk) 14:57, 14 November 2016 (UTC)[reply]
  • You can use statements on Wikidata to generate categories in LUA. Several Wikipedias already do that. No additional development is needed. --Jura1 (talk) 10:03, 21 November 2016 (UTC)[reply]
  • It is possible to automate some categories, but not all, and it is not clear which one can be automated. Categories in Wikipedia follow mostly theme, and it is difficult to automate creation of them. Those that follow topic can sometimes be automated. It is although easier to automate maintenance of existing categories than automate creation of them, and that does not imply any specific interpretation of the content. — Jeblad 10:49, 30 November 2016 (UTC)[reply]

Voting –More database functions

  1.   Oppose You have clearly not tried to synchronize categories across language projects before. Jane023 (talk) 10:34, 30 November 2016 (UTC)[reply]

Move lexicon-like external sites as wd-statements, and add them back under section headers

  • Problem: Some links to external sites are links to content organized as a lexicon, like links to w:Encyclopedia Brittanica. Such links should be on Wikidata, and inserted as necessary under "External links". Without some additional magic we will only replace one nightmare with another, that is maintenance of the template itself.
  • Who would benefit: Sites organized around lexicon-like structures.
  • Proposed solution: Create a gadget to move external links to Wikidata, it is already a property described by source for this purpose, and then add the statements back by using system messages attached to the section headers. Let those messages contain wikitext with calls to templates and/or modules so the statements to such lexicon-like sites can be added back automatically.
  • More comments: This gadget should be on the client sites, not on the repo, even if the links are moved to the repo. It will be a bit like quick statements, but focused on a single core function.
If used without any restrictions it can make it difficult to track why something shows up on a page, especially in raw wikitext. This can be avoided by limiting the insertion points to section headers and a few other markers.
Somehow the links should be limited to avoid creating link farms.
  • Phabricator tickets:

Community discussion

Good point. The template insertion mechanism is important to this proposal, but it is useful on its own. The template insertion proposal became much to technical, so it could be better to add it here. Or even rewrite the proposal. I'll take a look tomorrow. — Jeblad 03:50, 23 November 2016 (UTC)[reply]
Functionality to add the links back can generalized, although it is not necessary for this proposal. A proposal more specific to this kind of functionality is described on 2016 Community Wishlist Survey/Categories/Miscellaneous#Feature for addition of common templates. Whats described here does only need injection of system messages to work, not the more general injection by regex patterns. — Jeblad 11:00, 23 November 2016 (UTC)[reply]
This is somewhat related to Add a new MediaWiki system message at the footer of content pages. — Jeblad 15:37, 25 November 2016 (UTC)[reply]
Or, just get rid of external links, since if they're useful they should be references in the article anyway! Thanks. Mike Peel (talk) 22:24, 1 December 2016 (UTC)[reply]

Voting – Move lexicon-like external sites as wd-statements

Primary Sources gadget: important bugs

  • Problem: The Primary Sources gadget development by Google stopped at some moment, the community lacks the knowledge to fix the current bugs (the backend is C++ for example) or to improve the gadget. It shouldn't also be the most important subject of the development team of Wikidata.
  • Who would benefit: editors and users of the data of Wikidata (faster workflow).
  • Proposed solution: find experienced developers willing to improve and fix the code of the gadget.

Community discussion

Proposal needs improvement: @Sjoerddebruin: Currently this proposal does not meet the requirements outlined in 2016 Community Wishlist Survey#What happens during the proposal phase?, as "Improve and fix" is not specific enough and several different requests (47 different tasks currently, according to the Phabricator link) are squashed into one single proposal. Could you please identify the (maximum three) top problems that you see and split them into separate proposals (as you can hand in up to three proposals for the Community Wishlist)? That would also improve chances that the Community Tech might work on this (as I don't see them fixing all 47 open Phabricator tasks) and would help everybody to understand what exactly is requested in your proposal when discussing, voting, or working on fixing issues. Thanks in advance! --AKlapper (WMF) (talk) 13:19, 10 November 2016 (UTC)[reply]

Okay, sorry. I think these are the largest issues:
  • Qualifiers and sources are suggested with new statements instead of existing ones, it also doesn't seem to check if a statements already exists (phab:T139757)
  • Some suggestions are unrejectable (phab:T147330)
  • And it would be great if at least the frontend part could be translated (phab:T148143)
Sjoerd de Bruin (talk) 14:15, 10 November 2016 (UTC)[reply]
In my opinion the most important task with the Primary Sources tool is stopping the reloading of the page when the user approves claims.
(Note: ChristianKl proposed this below at #Primary Sources: When a claim from the tool gets approved, the page shouldn't get reloaded.) Quiddity (WMF) (talk) 00:05, 23 November 2016 (UTC)[reply]
As long as the data sources are mostly in English I don't think translation of the front end should be a priority. A user that can't speak English shouldn't approve claims based on English sources. ChristianKl (talk) 18:19, 10 November 2016 (UTC)[reply]
FYI: There is an open grant request to work on the Primary Sources Tool issues: Grants:IEG/StrepHit: Wikidata Statements Validation via References/Renewal --Lydia Pintscher (WMDE) (talk) 08:28, 23 November 2016 (UTC)[reply]

Voting – Primary Sources gadget

  1.   Support--Wesalius (talk) 08:20, 28 November 2016 (UTC)[reply]
  2.   Support --Izno (talk) 01:25, 29 November 2016 (UTC)[reply]
  3.   Support -- Mushroom (talk) 22:07, 29 November 2016 (UTC)[reply]
  4.   Support --Jklamo (talk) 15:03, 30 November 2016 (UTC)[reply]
  5.   Support --Nouill (talk) 14:23, 1 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Wikidata&oldid=24950215"