Community Wishlist Survey 2022/Wikidata

Wikidata
26 proposals, 233 contributors, 618 support votes
The survey has closed. Thanks for your participation :)



Do not follow sitelink redirects when redirect badge is used

  • Problem:
     
    The red arrow points to the intentional sitelink to redirect (Q70894304) badge. The green arrow points to the badge selector icon which can be used to add badges.
    Sitelinks to redirects that appear as a result of a Wikimedia page being converted into a redirect page in the corresponding Wikimedia project should be tagged with the sitelink to redirect (Q70893996) badge. When intentionally adding a new sitelink to a redirect on Wikidata, the redirect should be tagged with the badge intentional sitelink to redirect (Q70894304). Usage of both badges is accessible via WDQS.

    A review of unbadged redirect sitelinks and sitelinks with the sitelink to redirect (Q70893996) badge, but without the intentional sitelink to redirect (Q70894304) badge allows a removal of invalid redirect sitelinks or an upgrade to the intentional sitelink to redirect (Q70894304) badge in case the redirect sitelink is valid and should be kept permanently.

    Currently, redirect pages on Wikimedia projects can still not be connected to Wikidata items as sitelinks. As long as the technical possibility of adding Wikidata items directly is not implemented it is required to use a workaround as follows (please mind that this workaround is controversial in some projects and may lead to complaints):

  1. The user has to first make an edit at the Wikimedia project that deactivates the redirect (e.g. by removing the hash symbol from #REDIRECT to REDIRECT)
  2. The sitelink can now be added to the Wikidata item, including the desired redirect badge; this cannot be done when the page is an active redirect page
  3. Finally, the deactivated redirect page has to be activated again by undoing the edit from step 1.
  • Proposed solution: We want to allow sitelinks to redirects but only under certain conditions. In detail this means:

    The default behavior always tries to normalize sitelinks (following redirects) and thus these sitelinks are rejected in cases where the target of the redirect is already a sitelink. A sitelink to a redirected pages can be added to an Item if and only if a redirect badge (sitelink to redirect - sitelink to redirect (Q70893996), intentional sitelink to redirect - intentional sitelink to redirect (Q70894304)) is added in the same edit. Adding a redirect badge to an existing redirect sitelink should be possible. Removing a redirect badge from a sitelink that points to a redirected page should be disallowed.

  • Who would benefit: All users who work with connecting Wikipedia pages to Wikidata items
  • More comments:
  • Phabricator tickets: phab:T278962
  • Proposer: Heanor (talk) 20:49, 10 January 2022 (UTC)

Discussion

Some history of this topic:
I think we need this final step to start linking redirects properly. — putnik 22:54, 10 January 2022 (UTC)
Just unlock the save button when any extant mainspace title is in the input box, without checking whether it is a redirect. It got 65 votes last year, we've been asking for it since 2015, and implementation seems as trivial as these things can get given the need for proper testing. Certes (talk) 18:54, 11 January 2022 (UTC)
(this is not a vote, but primarily an alternative proposal about the "how") Support with modifications. Discard the badges at wikidata and use magic tag __VALIDREDIRECT__ on the linked wiki page instead. Let wikidata autodetect "redirect to page" vs "redirect to section" and display appropriate icon, and autodetect the presence of __VALIDREDIRECT__ and other details with a tri-state verdict
  • "intentional redirect" (__VALIDREDIRECT__ present, target of redirect linked to wikidata)
vs
  • "dubious redirect" (redirect but magic tag missing)
vs
  • "misuse of VALIDREDIRECT" (target of the redirect is an empty page, or a redirect, or a page (not section) not linked to wikidata).
Make it as simple as possible. The originally intended solution with 2 independent badges allows for a large number of dubious states. Taylor 49 (talk) 21:40, 14 January 2022 (UTC)
There's actually already an outline on how this should work, so I doubt that the development team would consider alternatives to it (provided that it ever addresses this issue). --Nw520 (talk) 18:04, 15 January 2022 (UTC)
Honestly, I'm dumbfounded that this hasn't been implemented yet. It took a full 7 months to receive any response from Wikidata's PO to a volunteer's patch that would've resolved this issue. At this point the community shouldn't even have to ask for addressing of this issue. --Nw520 (talk) 18:04, 15 January 2022 (UTC)

Voting

  •   Support particularly the part about avoiding the need to remove a redirect to be able to link to it from Wikidata - fixing that is long overdue. Mike Peel (talk) 18:45, 28 January 2022 (UTC)
  •   Support * Pppery * it has begun 18:56, 28 January 2022 (UTC)
  •   Support — Draceane talkcontrib. 22:24, 28 January 2022 (UTC)
  •   Support Certes (talk) 02:02, 29 January 2022 (UTC)
  •   Support More attention is needed to Wikidata and redirects. {{u|Sdkb}}talk 03:47, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:47, 29 January 2022 (UTC)
  •   Supportputnik 15:50, 29 January 2022 (UTC)
  •   Support Not sure what the best solution is but temporarily deactivating redirects should not be necessary. —Dexxor (talk) 16:50, 29 January 2022 (UTC)
  •   Support --Epìdosis 20:53, 29 January 2022 (UTC)
  •   Support--Alexmar983 (talk) 21:10, 29 January 2022 (UTC)
  •   Support Nw520 (talk) 23:16, 29 January 2022 (UTC)
  •   Support josecurioso ❯❯❯ Tell me! 00:41, 30 January 2022 (UTC)
  •   Support --Hsarrazin (talk) 07:09, 31 January 2022 (UTC)
  •   Support ArthurPSmith (talk) 15:57, 31 January 2022 (UTC)
  •   Support JAn Dudík (talk) 21:33, 31 January 2022 (UTC)
  •   Support Seini.coe (talk) 18:07, 2 February 2022 (UTC)
  •   Support preferably by means of the __VALIDREDIRECT__ magic string. Taylor 49 (talk) 00:02, 3 February 2022 (UTC)
  •   Support --MarieVirtuElle (talk) 01:49, 3 February 2022 (UTC)
  •   Support - Darwin Ahoy! 20:28, 4 February 2022 (UTC)
  •   Support Pelagic (talk) 05:43, 5 February 2022 (UTC)
  •   Support Kpjas (talk) 13:37, 5 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 09:22, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:10, 6 February 2022 (UTC)
  •   Support --Luan (discussão) 14:44, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:09, 7 February 2022 (UTC)
  •   Support Heanor (talk) 13:29, 8 February 2022 (UTC)
  •   Support 白布飘扬 (talk) 19:56, 8 February 2022 (UTC)
  •   SupportDaxServer (t · c) 14:53, 10 February 2022 (UTC)
  •   Support Dipsacus fullonum (talk) 23:34, 10 February 2022 (UTC)

Tool to bulk replace long-hand citations with items

  • Problem: Sometimes a cited source is subsequently added to Wikidata as an item. We need to be able to convert such citations to use the QID of that item, and to do so efficiently.
  • Proposed solution: A tool that will replace all instance of a selected citation on a given item (or set of items?) in one go.
  • Who would benefit: Wikidata editors
  • More comments: worked example; example diff
  • Phabricator tickets:
  • Proposer: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:19, 15 January 2022 (UTC)

Discussion

Voting

Dedicated section for everything meta on item pages

  • Problem: Commons gallery (P935), topic's main template (P1424), category for ship name (P7782) and many other Wikidata properties are used to store statements regarding Wikimedia projects themselves. These statements are left in the midle of item pages, where they mingle with the ones that deal with the external world and usually matter the most to third parties.
  • Proposed solution: I believe every statement regarding Wikimedia projects should be moved to a new dedicated section at the bottom of item pages, just before the interwiki links section. This section could be named 'Wikimedia', I guess.
  • Who would benefit: Everyone using item pages on Wikidata.
  • More comments: On top of changing the way item pages are displayed as suggested above, a new namespace in W:, instead of the normal one in P:, could be used for properties that deal with meta (i.e. Wikimedia) stuff. Think about it! Everything would be clearer.
  • Phabricator tickets:
  • Proposer: Thierry Caro (talk) 09:02, 11 January 2022 (UTC)

Discussion

  • Not sure whether this would help. This is basically a tweak for the web UI, but the underlying data does not have such a structure with a dedicated Wikimedia section. The Identifiers section already leads to some confusion occasionally.
    I can also imagine that there are or will be properties that somehow fit to both sections (the general one and the Wikimedia one), so where to place it? This problem also exists for a secondary property namespace. —MisterSynergy (talk) 20:19, 12 January 2022 (UTC)
  • I have been stressing the problem/issue/aspect for some years. While I can still tolerate some ID-level property such as WLM ID or Wiki username, there are also more peculiar wiki-related properties that IMHO should not clutter the section of statements, I also include P5008. --Alexmar983 (talk) 14:35, 15 January 2022 (UTC)

Voting

Entity Draft Namespace

  • Problem: There is no way to create draft entities on Wikidata
  • Proposed solution:
    • Create dedicated entity draft namespaces for Wikibase for Items, Properties, and Lexemes appropriately named "Item draft", "Property draft", "Lexeme draft". These will contain entity pages identical in form to their normal types. You will be able to add statements, change labels, etc. and they will have a Discussion page. Draft entities can be used as values in statements on other draft entities but not normal entities. Draft entities' statements' property and item autocomplete search fields should show Draft entities in their results.
    • Rename the new "Property draft" namespace on Wikidata to "Property proposal". "Property proposal" property pages will replace the current template-based property proposals. Users will create a proposal by creating a new page in the "Property proposal" namespace. They will add statements to the property just as they intend the property to look when copied to main "Property" namespace. Because draft entities can reference other draft entities, property proposals will be able to usefully use other property proposals and draft items in their statements. For example, if a property and subproperty is being proposed at the same time, the subproperty's proposal can add the subproperty of (P1647) statement and link to its parent property's proposal. Additionally, if a new data structure is going to be created from a property, the property's usage examples can use draft items that may not be appropriate to put into the database yet. The user will explain their motivation and discussion about the proposal on the proposal's Discussion page. Proposals will be categorized by subject and status from a template added to the Discussion page that adds the appropriate categories. When a property is ready to be created, a property creator will use a tool to copy the "Property proposal" entity page to a new property in the "Property" namespace. The proposal page will remain for historical preservation.
  • Who would benefit:
    • Property creators
    • All editors
    • Data importers
  • More comments:
    • Having dedicated entities will also allow the querying for proposals and their data - something we can't easily do at the moment due to data being managed by templates and categories.
    • Other organizations that use Wikibase also may find use of this. They may not want all data published to the main entity namespaces and may want to experiment or verify new parts of their ontologies or data about to be added. These namespaces allow them to do this without requiring them to setup a separate instance of Wikibase.
  • Phabricator tickets: phab:T298405
  • Proposer: Lectrician1 (talk) 21:07, 10 January 2022 (UTC)

Discussion

I have hesitated to start writing property proposals because I neither wanted to setup up a document to store my draft, nor finish it all in one session. Of course having a draft space would fix that. Blue Rasberry (talk) 21:19, 11 January 2022 (UTC)

The <translate></translate> tags are currently not rendered correctly here. I have created Community Wishlist Survey 2022/Translation/Make "translate" tags always render correctly for addressing this issue. GeoffreyT2000 (talk) 15:14, 22 January 2022 (UTC)

Voting

  •   SupportThe Editor's Apprentice (talk) 18:53, 28 January 2022 (UTC)
  •   Support Bluerasberry (talk) 19:49, 28 January 2022 (UTC)
  •   Support I like the idea of having a sandbox equivalent that's not a Wikidata Sandbox item. Drafting property proposals can be collaborative and sorting that out *before* community input would be nice (and probably help address issues before the community even needs to weigh in). Wskent (talk) 19:57, 28 January 2022 (UTC)
  •   Support Aca (talk) 15:50, 29 January 2022 (UTC)
  •   Support Nw520 (talk) 23:31, 29 January 2022 (UTC)
  •   Support Joshbaumgartner (talk) 00:09, 30 January 2022 (UTC)
  •   Support Dhx1 (talk) 00:17, 30 January 2022 (UTC)
  •   Support This would allow me to demo alternate ways of modelling a subject area, mixing in real properties and values from non-draft space. Pelagic (talk) 09:02, 30 January 2022 (UTC)
  •   Support This could also help model changes to existing entities, i.e. the draft could use a current property for a template and allow trying out alternative constraints which could be worked into the original property after community approval of the draft. SM5POR (talk) 09:44, 30 January 2022 (UTC)
  •   Support I think this would be a better alternative than the "Property proposal helper script" idea also suggested this year. Property creators would need to have the ability to move properties from draft to non-draft namespace. ArthurPSmith (talk) 15:53, 31 January 2022 (UTC)
  •   Support Silver hr (talk) 20:55, 2 February 2022 (UTC)
  •   Support Drafts would ease workflow. Rotavdrag (talk) 11:06, 3 February 2022 (UTC)
  •   Support Drafts to approve items and properties Thingofme (talk) 14:31, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 19:37, 4 February 2022 (UTC)
  •   Support Drafts are good everywhere. Daniel Case (talk) 23:09, 5 February 2022 (UTC)
  •   Support Redalert2fan (talk) 14:51, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:02, 7 February 2022 (UTC)
  •   Support Marcok (talk) 07:25, 10 February 2022 (UTC)

Rework the suggestion model of PropertySuggester with support for values and units

  • Problem: The feature of PropertySuggester is not complete and ideal. In some cases they are even useless.
  • Proposed solution: Rework the suggestion model of PropertySuggester, with a support of suggesstion of values (and ideally units).

(original:

  1. PropertySuggester should (i) also suggest values; (ii) suggest meaningful items for units.
  2. Commons Structured Data also need a PropertySuggester implementation

)

Discussion

  • @GZWDer: Hello and thanks for proposing this! In discussing this with CommTech engineers, we're wondering if you could trim this down to your most-wanted solution of the two. They noted that "Commons Structured Data also need a PropertySuggester implementation" would likely be the less-common use case, but definitely open to your feedback. LDelench (WMF) (talk) 02:41, 25 January 2022 (UTC)
    • Updated the proposed solution.--GZWDer (talk) 21:40, 25 January 2022 (UTC)

Voting

Search box autocomplete (suggestion) should work for all namespace

  • Problem: For example, if you type "Wikidata:Project ch" it should suggest the Wikidata page (not item) for Project chat. Currently the SearchAll gadget is used as a workaround.
  • Proposed solution: Ideally, get rid of Wikidata overriding the whole search box, and instead make it run standard API request and have small(er) pluggable Wikidata part than runs the second request.
  • Who would benefit:
  • More comments: This is first raised in 2013.
  • Phabricator tickets: phab:T190454; see also phab:T194968 (also need considering)
  • Proposer: GZWDer (talk) 09:40, 21 January 2022 (UTC)

Discussion

Voting

A tool to delete all references from an item

  • Problem: When, for example, one has duplicated an item but does not need the sources; or when one has found a better source for an item with only poor quality sourcing, removing all the source is time-consuming.
  • Proposed solution: A tool (gadget?) that puts a button or link on the page that, when clicked and confirmed, removes all citations
  • Who would benefit: Wikidata editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 15 January 2022 (UTC)

Discussion

  • I would use this function a lot. - PKM (talk) 02:10, 18 January 2022 (UTC)
  • This sounds useful, but it seems like it would also make vandalism much easier. Silver hr (talk) 20:07, 2 February 2022 (UTC)
  • It is unhelpful to add an "oppose" without explaining the grounds. As for "easier vandalism", that would just as easily be revertable; but the ability could be restricted to auto conformed users. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:19, 8 February 2022 (UTC)
  • you can use this regular expression (?<=\<ref\>)[^\<\/ref\>]+ and use it here (coding.tools). To replace all contents of the <ref></ref>, while leaving the delimiters, so that you know, where a Reference needs to be added. Is that a tool enough? (Copy the expression here, if you want it to be explained: [1]) --Saippuakauppias (talk) 15:52, 20 April 2022 (UTC)

Voting

  •   Support Lectrician1 (talk) 02:30, 29 January 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:18, 29 January 2022 (UTC)
  •   Oppose KingAntenor (talk) 07:05, 2 February 2022 (UTC)
  •   Oppose easier vandalism. Maybe autoconfirmed users can quick blank an item? Thingofme (talk) 14:20, 4 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:47, 6 February 2022 (UTC)
  •   OpposeDaxServer (t · c) 12:42, 10 February 2022 (UTC)

Accessing items with particular statements via Lua

  • Problem: A number of Wikidata's properties are essentially inverses—"part of administrative territory" and "contains administrative territory", "has part" and "part of", and so on. This redundancy, however, has led in many instances, and has the potential in many others, to cause an excess amount of bloat—thousands of "owner of" values caused items for Japanese prefectures and India's rail operator to be briefly unmanageable, thousands of "part of" values caused items for chemical elements to be briefly unmanageable, thousands of values for "child astronomical body" are currently making it difficult to manage the item for the Sun, and lots of values for "head of government" on an item X are frequently redundant and go out of sync with the list of items with "position held" (head of government of X). A number of proposals to delete some inverse properties have been stalled precisely because they are required for other wikis to display information that is otherwise stored on the target items themselves.
  • Proposed solution: provide in the Lua interface a function similar to the "haswbstatement" keyword in Wikidata's text search: supposing this function were named "haswbstatement", a call in Lua to haswbstatement('P39', 'Q839078') would return a list of items for individuals that are or were Prime Ministers of Canada.
  • Who would benefit: all other Wikimedia wikis which use Lua to access Wikidata's data
  • More comments: ** The Wikidata Query Service's Linked Data Fragments endpoint already allows a property (as a predicate) and an item or other value (as an object) to be specified so that items with the resulting statement (as subjects) can be returned and possibly paged through. (Here 'subject', 'predicate', and 'object' refer to any such entity within Wikidata's RDF triple store.) In addition to the functionality desired above, if it is possible, being able to ask for predicates matching a subject-object pair might also be useful.
    • There is a gadget which displays "inverse properties", but this does not inherently solve the inverses problem that client wikis have since it does not run on the server side.
    • Some initial concerns about inverses were raised as ArthurPSmith's and my own oppose votes on this 2019 Wishlist proposal, and this proposal would cut the scope of properties to which this current Wishlist proposal applies.
  • Phabricator tickets: phab:T199887, phab:T209559 (directly) phab:T185313 (indirectly)
  • Proposer: Mahir256 (talk) 22:54, 10 January 2022 (UTC)

Discussion

  • A perennial problem, which is why people keep proposing inverses to existing properties. Solving this would be very helpful. ArthurPSmith (talk) 19:48, 11 January 2022 (UTC)
  • IMO, this is the biggest systemic issue with Wikidata data models and cuts across every model and almost every relational property. Having an ad hoc mishmash of properties, some with inverses and some not, is a nightmare for using the data, maintaining it, reasoning about it (how sure am I all the inverses match?) as well as making it painful to create items because you get constraint violations for missing inverses. Which also shows something, somewhere already knows the answer! Inductiveload (talk) 23:09, 12 January 2022 (UTC)
  • Would be very useful at least in ru-wiki Ghuron (talk) 17:47, 19 January 2022 (UTC)
  • As a music editor on WD I see a lot of bad modelling stemming from the needs of different Wikipedias. This reads like something that would greatly benefit both projects. Moebeus (talk) 11:31, 21 January 2022 (UTC)
  • Having manually defined inverse properties is redundant (in a bad way) and unsustainable. Conceptually, every property defines its own inverse automatically. If performance is the problem, then the solution should be at a low level--for example, the system could define a hidden entry for a property inverse and maintain a cache automatically, and none of this should be visible to the user. Silver hr (talk) 20:00, 2 February 2022 (UTC)
  • Making inverse relationships/statements visible in the Wikidata GUI is already possible with the built-in Gadget "[ ] relateditems: Adds a button to the bottom of item pages to display inverse statements." Geert Van Pamel (WMBE) (talk) 12:10, 3 February 2022 (UTC)
  • Good idea; I've encountered similar issues of redundancy, not due to inverse claims, but due to poor aggregation of identical values, such as stating the time zone for each of 100,000 villages and other locations in China, when all of China runs on the same time zone anyway, as well as a rumored desire among WP editors to hand-pick property claims based on what looks good in WP infoboxes (such as preferring P361 part of over P279 subclass of as a matter of style, in spite of the different ontological implications). This problem is essentially what got me into Lua programming and trying to model the rules for implied property values (including inheritance and transitivity) in Swedish Wikipedia a year and a half ago, but I didn't have the time to continue working on it then; I may resume it later. Your suggested approach looks very much in line with mine. --SM5POR (talk) 07:16, 4 February 2022 (UTC)

Voting

  •   Support Moebeus (talk) 18:23, 28 January 2022 (UTC)
  •   Support - this would be really useful for infobox development work, but this is quite tricky as it basically means running a query on Wikidata to get a list of the results (which would actually be really useful in Lua as well!). Thanks. Mike Peel (talk) 18:47, 28 January 2022 (UTC)
  •   Support * Pppery * it has begun 18:57, 28 January 2022 (UTC)
  •   Support Inductiveload (talk) 20:01, 28 January 2022 (UTC)
  •   Support Izno (talk) 00:09, 29 January 2022 (UTC)
  •   Support Fralambert (talk) 00:26, 29 January 2022 (UTC)
  •   Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:31, 29 January 2022 (UTC)
  •   Support Tpt (talk) 13:35, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:39, 29 January 2022 (UTC)
  •   Support Ainali talkcontributions 15:46, 29 January 2022 (UTC)
  •   Support really very important. Cheers, VIGNERON * discut. 20:10, 29 January 2022 (UTC)
  •   Support Lectrician1 (talk) 20:11, 29 January 2022 (UTC)
  •   Support I'd love to see this implemented and look very much forward to voting in favour of deletion for all those useless inverse properties which solely exist to allow efficient Lua-querying. Nw520 (talk) 23:28, 29 January 2022 (UTC)
  •   Support josecurioso ❯❯❯ Tell me! 00:43, 30 January 2022 (UTC)
  •   Support --Hsarrazin (talk) 06:48, 31 January 2022 (UTC)
  •   Support JAn Dudík (talk) 09:20, 31 January 2022 (UTC)
  •   Support Yes! ArthurPSmith (talk) 15:54, 31 January 2022 (UTC)
  •   Support Geert Van Pamel (WMBE) (talk) 15:52, 2 February 2022 (UTC)
  •   Support Silver hr (talk) 20:00, 2 February 2022 (UTC)
  •   Support This approach would address several issues at once, not only individual items becoming unmanageable, but also the general layout of the class tree. SM5POR (talk) 07:24, 4 February 2022 (UTC)
  •   Support Betseg (talk) 08:33, 4 February 2022 (UTC)
  •   Support Syced (talk) 10:45, 4 February 2022 (UTC)
  •   Support Thingofme (talk) 14:23, 4 February 2022 (UTC)
  •   Support "cheap" - Efficiency will become vital. Vollbracht (talk) 15:26, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 21:37, 4 February 2022 (UTC)
  •   Support Hanif Al Husaini (talk) 12:11, 5 February 2022 (UTC)
  •   Support Kpjas (talk) 13:33, 5 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:10, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:08, 7 February 2022 (UTC)
  •   Support Arvelius (talk) 20:47, 7 February 2022 (UTC)
  •   SupportDaxServer (t · c) 12:49, 10 February 2022 (UTC)
  •   Support Dipsacus fullonum (talk) 00:30, 11 February 2022 (UTC)
  •   Support Valerio Bozzolan (talk) 17:20, 11 February 2022 (UTC)
  •   Support. Geagea (talk) 21:42, 16 May 2022 (UTC)

Creation of new objects resp. connecting to existing objects while avoiding duplicates

Discussion

  • For some new users they may pick a random item in suggestion in connect without looking at it carefully, which will result in errors more difficult to discover than duplicates.--GZWDer (talk) 14:48, 11 January 2022 (UTC)
    So the display should present sufficient information to disambiguate (description, instance of, country or location property..., image?). Maybe that's hard, but at the least, the suggested "translation" logic would make a lot of sense to implement. ArthurPSmith (talk) 19:46, 11 January 2022 (UTC)
  •   Comment I'm not sure what differs between this proposal and the one "Autosuggest linking Wikidata item after creating an article"?? ArthurPSmith (talk) 15:49, 31 January 2022 (UTC)
    Indeed, they seem to ask for the same thing. Silver hr (talk) 20:20, 2 February 2022 (UTC)
  • There exists a gadget "[ ] moveClaim: A tool to move or copy a statement from one entity to another" that allows to duplicate a statement to another item, taking care not to create duplicate statements. Geert Van Pamel (WMBE) (talk) 16:43, 4 February 2022 (UTC)
Hello @Geertivp: this proposal is about duplicate items/objects, not duplicate statements in one single item/object. For example, one item/object might be connected to the english article, while another item/object, describing the same entity (the same person, the same film the same book, the same geografical object, ...), is not connected to any article or project or to an article in different language(s). The proposed popup might look like this:

--M2k~dewiki (talk) 11:03, 5 February 2022 (UTC)

Voting

  •   Support — Draceane talkcontrib. 22:25, 28 January 2022 (UTC)
  •   Support For new users it may not be easy to pick the correct / intended Wikidata item but otherwise it could become an "opt-in" functionality which is mostly used by people who regularly create articles. Simeon (talk) 21:09, 29 January 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:21, 29 January 2022 (UTC)
  •   Support Thingofme (talk) 14:28, 4 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:51, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:05, 7 February 2022 (UTC)
  •   Support Hroptatyr (talk) 05:55, 11 February 2022 (UTC)

Autosuggest linking Wikidata item after creating an article

  • Problem: Someone creates an article in Language A Wikipedia, but he does not know there is already the same article in Language B Wikipedia (often a smaller language version), so no Wikidata linkage is made. I have seen many cases between Chinese Wikipedia (zh) and Cantonese Wikipedia (yue).
  • Proposed solution: After creating an article in Wikipedia, there would be a popup which guides the user to link the Wikidata item. The system will search if there is the same name or similar name of sitelinks already existing in any Wikidata item, if so, the results are listed and the user has to judge whether it is suitable to link. If no existing Wikidata is suitable to link, user can also choose to create a new Wikidata item immediately.
  • Who would benefit: Wikipedia article creators in all languages
  • More comments:
  • Phabricator tickets:
  • Proposer: Kwgulden (talk) 11:06, 23 January 2022 (UTC)

Discussion

  •   Comment Just to add here from the perspective of the Wikimedia Enterprise team: That variations of this suggestion have been made to us during our conversations with some large-scale commercial organisations who re-use Wikipedia content. They would also like to see greater connectivity between WD and WP and feel this would improve the quality of their products (which, ultimately, improves quality of Wikimedia knowledge which is reaching the general public via those services). This should not be seen as a factor in community-driven technical prioritisation, but is to point out that this wishlist item would be desired by third-parties, too. LWyatt (WMF) (talk) 14:39, 2 February 2022 (UTC)

Voting

Creation protection for items

  • Problem: When there is a spam in Wikipedia and we delete the page, they create again and then we simply protect the title against creation. In Wikidata, this is not possible and a spammer easily moves on a newer Qid and has been a game of cat and mouse all the time.
  • Proposed solution: Have a way to easily protect an item against recreation under another Qid
  • Who would benefit: Admins and patrollers of Wikidata. Users of wikidata due to improved data quality
  • More comments:
  • Phabricator tickets:
  • Proposer: Amir (talk) 12:45, 15 January 2022 (UTC)

Discussion

Hard to see how this is do-able; but a work-around might be an edit filter to block a certain external ID value. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:58, 15 January 2022 (UTC)

It can be bound to label for example. The problem is that abuse filter slows down every edit in wikidata. Amir (talk) 14:43, 21 January 2022 (UTC)

Voting

Feature to change the order of the references and qualifiers

  • Problem: Can't change the order of the declarations, qualifiers and references
  • Proposed solution: Make a feature to change the order of them and even automatically class the reference per date of publication for exemple
  • Who would benefit: The contributors/editors
  • More comments:
  • Phabricator tickets: phab:T169960
  • Proposer: Noecmm (talk) 20:23, 12 January 2022 (UTC)

Discussion

  • @Noecmm: Would ordering qualifiers and references by global property order suffice for your use cases? As described in phab:T169960. Or is a manual, per-item, order required? —SWilson (WMF) (talk) 05:42, 14 January 2022 (UTC)
  • There is a user script that allows to do it for statements. But in most cases, the input order should not matter, and the output sort should be determined based on the data. Therefore, it is better to think about improving the data model here. — putnik 09:19, 14 January 2022 (UTC)

Voting

  •   Support — Draceane talkcontrib. 22:22, 28 January 2022 (UTC)
  •   Support --Epìdosis 21:01, 29 January 2022 (UTC)
  •   Support --Alexmar983 (talk) 21:08, 29 January 2022 (UTC)
  •   Support Mitar (talk) 20:51, 2 February 2022 (UTC)
  •   Support Thingofme (talk) 14:31, 4 February 2022 (UTC)
  •   Oppose order is meaningless on wikidata. there is no good reason to do this and it clutters history. BrokenSegue 03:17, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:38, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:04, 7 February 2022 (UTC)
  •   Support --Oursana (talk) 16:14, 10 February 2022 (UTC)
  •   Oppose pr. BrokenSegue --Dipsacus fullonum (talk) 23:28, 10 February 2022 (UTC)

haswbsitelink keyword

  • Problem: Currently you can not find items with sitelinks to English Wikipedia but without English labels, or number of items with cebwiki sitelink and GeoNames ID (you can see the SPARQL queries at the linked Phabricator task, but both queries will time out).
  • Proposed solution: add a haswbsitelink keyword similar to haswbstatement.
  • Who would benefit:
  • More comments:
  • Phabricator tickets: phab:T200859
  • Proposer: GZWDer (talk) 09:50, 21 January 2022 (UTC)

Discussion

Voting

Rework Lexemes to be more intuitive

  • Problem: As it stands now, we have L3257-S1 (apple - english) with glosses in 7 languages and translations in 5. One of these translations, L53267-S1 (manzana - espanol) has the same meaning but only 3 glosses and 3 translation statements. Unifying all glosses and their statements across all language variants of a single sense manually is very time consuming and tedious.
  • Proposed solution: I'd suggest improving this process by not binding senses to a specific language. Have all glosses and statements linked to a particular sense (as it is now), and then link that single sense to all respective languages, to avoid missing or duplicated data.
  • Who would benefit: All lexeme editors
  • More comments:
  • Phabricator tickets: phab:T290858
  • Proposer: —Ivi104 01:26, 12 January 2022 (UTC)

Discussion

Have you given any thought to where information on senses that is tied to particular lexemes with respect to those senses should go after such a transition? How should the language styles of senses (to separate e.g. L361-S1 vs. {L7669-S1}), the citable definitions (of a word for "fly" in a German dictionary vs. that of "letjeti" in a Russian one), different conceptions of antonymy across languages (the word for "dark" having a different antonym in French vs. Persian), regional indications of senses ("bubbler" being a generic English noun but with the specific meaning "drinking fountain" in Wisconsin, while other languages might have words for this without region constraints), indications of specialization of senses (military-specific use of the Bokmål "perm" meaning "leave of absence" vs. "permisjon" with the same meaning), different behaviors of arguments of lexemes with respect to senses (English "to like" having a nominative liker and accusative likee, but German "gefallen" with the same meaning having a dative liker and nominative likee), and so on be indicated if the senses themselves are forced to be centralized? Mahir256 (talk) 22:00, 12 January 2022 (UTC)

@Mahir256: I'm not a linguist so I haven't thought that far ahead. I think this could be handled by making a new "Sense:" namespace that could be tied to a particular meaning of a particular lexeme.
As it stands now, Lexemes are tied to languages - what if lexemes and senses were multilingual, and the properties of a sense could differ according to a specific language? All languages have a concept (a sense) of an apple, a concept of love, a concept of flying, and they are all the same. That same sense has a different name and different connections (properties) in a particular language - e.g. French and Persian "dark" have a different antonym. I am very much looking forward to feedback - this is just an idea off the top of my head. —Ivi104 00:39, 15 January 2022 (UTC)

Voting

  •   Support Love the lexeme project but yes it needs design to be more user friendly to input data. Bluerasberry (talk) 19:51, 28 January 2022 (UTC)
  •   Support Aca (talk) 15:46, 29 January 2022 (UTC)
  •   Support Warmglow (talk) 17:06, 29 January 2022 (UTC)
  •   Support Libcub (talk) 00:04, 31 January 2022 (UTC)
  •   Support Novak Watchmen (talk) 17:20, 31 January 2022 (UTC)
  •   Support Fix some lexeme problem now! Thingofme (talk) 14:30, 4 February 2022 (UTC)
  •   Support Waldyrious (talk) 00:44, 6 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:45, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:03, 7 February 2022 (UTC)

Property proposal helper script

  • Problem: The property creation process is complicated, and a gadget may ease the work of property creators.
  • Proposed solution: Tool process:
    1. Create the property with the proper label/description
    2. Copy the information from the template to the newly created property
    3. Modify the template with the property number
    4. Ping the participants in the property proposal
  • Who would benefit:
  • More comments:
  • Phabricator tickets: phab:T139898
  • Proposer: GZWDer (talk) 09:42, 21 January 2022 (UTC)

Discussion

@GZWDer see also Community Wishlist Survey 2022/Wikidata/Entity Draft Namespace.

Voting

  •   Support yes please, at least the link to the url of the discussion page, the insertion of the "ready" field in the template, the insertion of some infoboxes in the talk pages of the property, the core instances, the set up of Wikidata property examples... it would really speed up the work. I know we don't have a lot of occurrences but it's really useful to simplify our job.--Alexmar983 (talk) 21:06, 29 January 2022 (UTC)
  •   Support This would be very nice indeed. It might have to be a bit flexible as sometimes there are problems with the property proposal template (for example the regex properties are often wrong) - so leave out anything from the template that doesn't work. ArthurPSmith (talk) 15:52, 31 January 2022 (UTC)
  •   Support Silver hr (talk) 20:48, 2 February 2022 (UTC)
  •   Support We can draft the property for the proposal Thingofme (talk) 14:24, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 21:11, 4 February 2022 (UTC)
  •   Support Lutzto (talk) 17:23, 5 February 2022 (UTC)
  •   Support Daniel Case (talk) 19:44, 5 February 2022 (UTC)
  •   Support Waldyrious (talk) 00:32, 6 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:40, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:08, 7 February 2022 (UTC)
  •   Support Rdrg109 (talk) 14:54, 11 February 2022 (UTC)
  •   Support MasterRus21thCentury (talk) 15:10, 11 February 2022 (UTC)

Import references from wikipedia

  • Problem: References contained in wikipedia's article need to be manually added to the wikidata object page.
  • Proposed solution: bot to check references of an article and add to related wikidata page.
  • Who would benefit: Increases credibility of information to readers and streamlines editors' work.
  • More comments:
  • Phabricator tickets:
  • Proposer: Elilopes (talk) 18:30, 20 January 2022 (UTC)

Discussion

  • How do you propose this bot will work? This is a very hard problem in general (natural language processing--the reason we have Wikidata is to get away from that in some ways), and wikitext makes it doubly so. --Izno (talk) 05:51, 21 January 2022 (UTC)
    Alternatively, a gadget would probably work quite well, I just don't know if such a gadget would be technically viable (a browser extension might be). --Izno (talk) 05:52, 21 January 2022 (UTC)
    For references with DOI, Magnus's bot regularly imported them to Wikidata (but it is probably not active nowadays). References still need to be added to Wikidata items manually. phab:T199197 may help.--GZWDer (talk) 10:46, 21 January 2022 (UTC)
  • A workflow to convert existing well-structured references to be hosted on Wikidata is needed until Wikipedia defaults to using Wikidata for references and all legacy references are converted. In cases where this is completely defined (such as DOIs), a bot could do it; in other cases it would probably be wiser for there to be a gadget that presents the suggested change to the user, and after approval (and any necessary changes) does the work of adding the reference to Wikidata (or finding it if it already exists) and making the Wikipedia edit to replace the old reference with the new one. Silver hr (talk) 20:28, 2 February 2022 (UTC)
  • Even collecting references from linked Wikipedias, and exposing them on or near a Wikidata item would likely lead to some ease in reference adding. This would be quite neat ·addshore· talk to me! 23:06, 4 February 2022 (UTC)

Voting

Timeline visualisation of items based on their genealogical properties (inspired by, cited by, etc.)

  • Problem: Lack of visualization tools for displaying items along a timeline with a graph view (the default graph view is fuzzy and it could be more structured on a timeline)
  • Proposed solution: adapting the graph view program
  • Who would benefit: regular users, mundane users (help people understand the value of Wikidata). Maybe Wikipédia pages could benefit from such a visual insert automatically (like info boxes)
  • More comments:
  • Phabricator tickets:
  • Proposer: Pmartinolli 16:43, 19 January 2022 (UTC)

Discussion

  • In seeking to use Wikidata/SPARQL to visualise the emergence, consolidation and contraction of network initiatives (such as railways, sports leagues), I have been both enthused and frustrated by the capabilities of the available tools. Although a time-base can be simulated using layers on a Map, for example, presenting a better network-through-time view is either not possible or beyond my coding skill. The Graph view is especially powerful but also lacking that timeline possibility. Pmartinolli, I wonder if this needs a more detailed proposal, though - or if a list of possible visualisation enhancements exists somewhere? AllyD (talk) 11:03, 20 January 2022 (UTC)
  • @Pmartinolli: Could you link to an example of what sort of visualization you have in mind? Are there other existing systems that do what you're proposing, that we could adopt? No worries if not, this can proceed to voting, but it'd just help people understand a bit more about this proposal. Thanks! SWilson (WMF) (talk) 07:05, 28 January 2022 (UTC)

Voting

  •   Support Malexan (talk) 13:27, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:55, 30 January 2022 (UTC)
  •   Support AllyD (talk) 11:39, 2 February 2022 (UTC)
  •   Support Interesting idea! Buzzsleeper (talk) 20:23, 2 February 2022 (UTC)
  •   Support Nclairoux (talk) 20:29, 2 February 2022 (UTC)
  •   Support CynG02 (talk) 20:46, 2 February 2022 (UTC)
  •   Support Visualization of items! Thingofme (talk) 14:23, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 01:54, 5 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:13, 6 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:48, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:10, 7 February 2022 (UTC)

Allow adding sitelink to redirect in Wikipedia section

  • Problem: In the Wikipedia part you can add Wikipedia projects. There are two options called "sitelink to redirect" and "intentional sitelink to redirect", but you can not select them. en:.375 Hölderlin for example redirects to en:8×68mm S. I have to remove the redirect on en:.375 Hölderlin, add the page to the Wikidata item and then insert the redirect again. Two avoidable edits that do not change the final result
  • Proposed solution: Allow adding a redirect or get rid of the option all together
  • Who would benefit: Users who want to link items to pages on Wikipedia that are redirects in a Wikipedia.
  • More comments:
  • Phabricator tickets:
  • Proposer: --D-Kuru (talk) 14:00, 18 January 2022 (UTC)

Discussion

Voting

Better ordering of search results

  • Problem: (This proposal have multiple usage and this is one of them) If you want to find items without label/description in specific language or sitelink in specific site, you may want to get the items with most statements/labels/sitelinks/identifiers first. (The second usage also require haswbsitelink keyword.)
  • Proposed solution: Order Wikidata search result by number of statements/labels/sitelinks/identifiers
  • Who would benefit:
  • More comments:
  • Phabricator tickets: phab:T236992
  • Proposer: GZWDer (talk) 09:46, 21 January 2022 (UTC)

Discussion

  • Wouldn't this favour for example, scholarly articles with heaps of bot-added statements, instead of another item that no one has got around to populating with statements? --Dhx1 (talk) 07:05, 29 January 2022 (UTC)

Voting

Automated page protector

  • Problem: Sister projects, especially large ones like the English Wikipedia, do not want to use Wikidata because it is prone to vandalisation. By exposing Wikidata to projects as big as the English Wikipedia, vandalism could increase sharply and human editors would not be able to keep up with reverts and page protection requests would overflow admins.
  • Proposed solution: An automated page protector bot or system that recognizes if a page is repeatedly being vandalised such as by tracking the number of reverts of edits made by inexperienced users and their ORES scores. It should then apply the appropriate page protection automatically after a number of identified forms of vandalism have occured.
  • Who would benefit: Everyone because using Wikidata has the power to significantly strengthen sister projects and the movement overall.
  • More comments: Not addressing the vandalism issue is a serious and cyclical problem that is holding back the huge potential for Wikidata. It goes like this: Wikidata isn't used much because it could be vandalised if exposed to the masses. Because it isn't used much it isn't vandalised and the tools to prevent it are not developed. We need to develop the tools to stop vandalism now so that other projects recognize Wikidata can handle it, and only then will they be willing to use it.
  • Phabricator tickets:
  • Proposer: Lectrician1 (talk) 06:45, 11 January 2022 (UTC)

Discussion

  • Wikidata changes for statements that are used other projects' pages should show up on that page's Watchlist Are you aware that this already happens? --Lucas Werkmeister (talk) 09:26, 11 January 2022 (UTC)
    Okay cool :) I wasn't sure or not. Lectrician1 (talk) 12:45, 11 January 2022 (UTC)
  • Note that heavily used items are already automatically protected by a bot: d:Wikidata:Requests for permissions/Bot/MsynABot. --Matěj Suchánek (talk) 09:31, 11 January 2022 (UTC)
  • Why not make ClueBotNG work on Wikidata? NightWolf1223 (talk) 15:50, 11 January 2022 (UTC)
    @NightWolf1223 That should probably be a separate proposal. Also, developing a system that can recognize the vandalism of pure data would be very hard because data points have little recognizable context and structure compared to human sentences. Providing page protection is a much more easy to implement and effective as it significantly reduces the chance of vandalism occuring in the first place. Lectrician1 (talk) 18:57, 11 January 2022 (UTC)
  • Currently ORES scores for Wikidata edits are not even remotely good enough to use them for such a task. In general, the entire revision-based scoring approach is not ideal for Wikidata with its atomic edits.
    We need to hope/wait for better scoring systems, and—for the time being—use the conventional patrolling function as a community much more that we currently do. —MisterSynergy (talk) 20:13, 12 January 2022 (UTC)
    @MisterSynergy I mean, I'm not looking for a system that scores Wikidata edits (though it could be involved). I'm looking for a system that tracks vandalism and does something about it. All it needs to do is track reverts on a page that were marked as vandalism and then protect that page after a number of occurrences. This shouldn't be that hard... Lectrician1 (talk) 05:29, 13 January 2022 (UTC)
    @Lectrician1: Could you clarify the proposed solution above to make it clear that this isn't only about using ORES scores? Thanks. —SWilson (WMF) (talk) 05:09, 14 January 2022 (UTC)
    @SWilson (WMF) done. I myself actually don't even know if ORES scores are available for Wikidata at the moment or if we have a way to mark reverts as vandalism... Can we do either of those? Lectrician1 (talk) 05:21, 14 January 2022 (UTC)
    It looks like ORES scores are a thing so I added that back in. Lectrician1 (talk) 05:31, 14 January 2022 (UTC)
    @Lectrician1: Looks good, thanks. I think the specific details can be figured out later once support for the general idea is established. — SWilson (WMF) (talk) 06:27, 14 January 2022 (UTC)
  • @Peter coxhead, Finnusertop, Sdkb, Bluebaor, and Fram: @Blueboar: You conveyed in either this village pump discussion or this one that Wikidata is prone to vandalism and that something needs to be done about it to allow for it's use on the English Wikipedia. This proposal seeks to build a tool to prevent vandalism for exactly that reason and I'd recommend you vote for it. Lectrician1 (talk) 19:41, 29 January 2022 (UTC)

Voting

  •   Support Sea Cow (talk) 19:03, 29 January 2022 (UTC)
  •   Support Silver hr (talk) 19:45, 2 February 2022 (UTC)
  •   Support Wikidata and Commons can be prone to vandalism. Thingofme (talk) 14:26, 4 February 2022 (UTC)
  •   Support Daniel Case (talk) 23:08, 5 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:49, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:11, 7 February 2022 (UTC)
  •   Support this is needed Carn (talk) 15:21, 11 February 2022 (UTC)
  •   Support You can take in consideration also blocks from sitelinks. Valerio Bozzolan (talk) 17:22, 11 February 2022 (UTC)

Display label of merge with items

  • Problem: Invalid merges of data items can result from mistyping the merge with item
  • Proposed solution: Display label of merge with item to confirm it is the intended item
  • Who would benefit: All wikidata editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Rouletteer (talk) 19:38, 11 January 2022 (UTC)

Discussion

Voting

  •   Support OwenBlacker (Talk) 11:46, 30 January 2022 (UTC)
  •   Support would be helpful for me ArthurPSmith (talk) 15:56, 31 January 2022 (UTC)
  •   Support Syced (talk) 10:38, 4 February 2022 (UTC)
  •   Support It's like merging wikilinks for the same/different one and merge the items Thingofme (talk) 14:25, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 20:39, 4 February 2022 (UTC)
  •   Support From my merging experience I think it'd be helpful. Kpjas (talk) 13:27, 5 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:12, 6 February 2022 (UTC)
  •   Support --Ciao • Bestoernesto 16:52, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:04, 7 February 2022 (UTC)

Corresponding properties

  • Problem: The software prompts users to make a corresponding edit in another item. This refers to pairs like father/child, Husband/Wife, but also to P1889 (item that is different from another item, with which it is often confused).
  • Proposed solution: Add a button "Yes do as proposed"
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: Bahnmoeller (talk) 23:19, 10 January 2022 (UTC)

Discussion

  • This sounds similar to the 2019 proposal Automatically add inverse properties, but without the automatic aspect. There's also T209559 Inverse statements duplicate work, data, and may be out of sync, which is of interest — but I can't find any exactly matching Phabricator task. In general, it sounds like it'd work on statements of properties that have an inverse property (P1696). SWilson (WMF) (talk) 04:35, 11 January 2022 (UTC)
  • Those suggestions likely come from the constraints system on wikidata, it defines how an property is supposed to be used. Each constraint is explained on the chat page of the property in question.--Snævar (talk) 04:42, 11 January 2022 (UTC)
  • I'd love to have some inverse relation for all properties that could have them. For instance, P9664 says that a place is mentioned in a map, good. But another P(9664^-1) saying in what maps a place is mentioned would be even better help. B25es (talk) 12:23, 11 January 2022 (UTC)
  • there is a good tool that allows to check, and add reverse properties in a click d:User:Frettie/consistency check add.js - I've used it for years now, and it really simplifies the work... - But an automatic prompt would clearly be simpler --Hsarrazin (talk) 16:10, 11 January 2022 (UTC)
  • I don't get what's being asked here. What kind of "corresponding edit" do you mean? If by that you mean a statement with an inverse property (where one is defined), I'll repeat my comment from the "Accessing items with particular statements via Lua" suggestion: "Having manually defined inverse properties is redundant (in a bad way) and unsustainable. Conceptually, every property defines its own inverse automatically. If performance is the problem, then the solution should be at a low level--for example, the system could define a hidden entry for a property inverse and maintain a cache automatically, and none of this should be visible to the user." Silver hr (talk) 21:03, 2 February 2022 (UTC)
    Exactly; this proposal risks amplifying the problem which "Accessing items with particular statements via Lua" is meant to address. Still, I often find myself adding those inverse claims merely to silence the "suggested edits" flags, as that is currently considered best practice. --SM5POR (talk) 08:53, 4 February 2022 (UTC)

Voting

Tool to replace author name string (P2093) with author (P50)

  • Problem: Manually replacing author name string (P2093) with author (P50) is time consuming, and risks loosing metadata
  • Proposed solution: A tool (gadget?) to replace author name string (P2093) with author (P50) given the QID of the author.
  • Who would benefit: Wikidata editors and data re-users
  • More comments: Example edit
  • Phabricator tickets:
  • Proposer: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 15 January 2022 (UTC)

Discussion

  • It seems like Author Disambiguator. --Epìdosis 14:29, 15 January 2022 (UTC)
    • No that tool's method is orthogonal to this wish, Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:40, 15 January 2022 (UTC)
      • @Pigsonthewing: Can you explain what you mean here? The issue is starting from a person (given QID) rather than from a name string? Author disambiguator already has an author page, it would be straightforward I think to create a link from that page to the name-matching page with variations on the author name; but I'm not sure that's what you're asking for here??? ArthurPSmith (talk) 18:45, 24 January 2022 (UTC)
        • It's not what I'm asking for. Did you see the example edit, above? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:02, 24 January 2022 (UTC)
          • The sample edit doesn't describe how you would get to that point. I guess you're envisioning a place to click on the item page for the scholarly article next to each P2093 value where you could paste in a QID for the replacement author? ArthurPSmith (talk) 17:58, 28 January 2022 (UTC)
  • Generally speaking it sounds like this should be a feature of the software ·addshore· talk to me! 23:12, 4 February 2022 (UTC)

Voting

Preview common properties in search & dropdowns

  • Problem: In Wikidata search results and in the hint dropdown that appears as you add new properties, you see the items' labels and their manually entered description field. Often, there is no manual description, so you have to open a bunch of similarly-named items in new tabs to determine if an item is a person, a building, a musical album, a disambiguation page, etc. But many of these items DO have some standard properties (e.g. "instance of") that would provide clarity in these cases.
  • Proposed solution: At minimum, some mechanism to see common properties like "instance of" without clicking into the item. Whether this is some sort of auto-generated description (like Reasonator creates) or some other mechanism, this would be quite handy. Or some sort of hover that shows a preview. I'm open to whatever might be possible. "Instance of" would help significantly; even more data (like birth/death dates for people) would be great.
  • Who would benefit: Anyone adding properties to Wikidata items or searching for a specific thing.
  • More comments:
  • Phabricator tickets:
  • Proposer: Sweet kate (talk) 00:37, 18 January 2022 (UTC)

Discussion

Would have supported if I had known voting ended at 18 UTC. ~~~~
User:1234qwer1234qwer4 (talk)
23:58, 11 February 2022 (UTC)

Voting

  •   Support Simeon (talk) 19:09, 28 January 2022 (UTC)
  •   Support Veracious (talk) 02:37, 29 January 2022 (UTC)
  •   Support Ottawajin (talk) 04:01, 29 January 2022 (UTC)
  •   Support Iamcarbon (talk) 04:18, 29 January 2022 (UTC)
  •   Support Higa4 (talk) 06:39, 29 January 2022 (UTC)
  •   Support Auto-generated descriptions would help immensely. For items without manual descriptions I think it would be necessary to check for two or more items with the same instance of/subclass of, and then for these items also check how they can be disambiguated by location, date, etc that may exist as other statements. Dhx1 (talk) 07:16, 29 January 2022 (UTC)
    Hard to implement in the vast majority of languages since I'm not aware MediaWiki knows anything about inflection at this point. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:57, 11 February 2022 (UTC)
  •   Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:29, 29 January 2022 (UTC)
  •   Support Meiræ 12:36, 29 January 2022 (UTC)
  •   Support HLFan (talk) 15:45, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:51, 29 January 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:19, 29 January 2022 (UTC)
  •   Support Nw520 (talk) 23:21, 29 January 2022 (UTC)
  •   Support —  HELLKNOWZ  TALK  enWiki 12:24, 30 January 2022 (UTC)
  •   Support Libcub (talk) 23:57, 30 January 2022 (UTC)
  •   Support Ariadacapo (talk) 10:23, 31 January 2022 (UTC)
  •   Support Sascha (talk) 06:49, 2 February 2022 (UTC)
  •   Support Geert Van Pamel (WMBE) (talk) 15:41, 2 February 2022 (UTC)
  •   Support Silver hr (talk) 20:49, 2 February 2022 (UTC)
  •   Support Have a manual list for the property like TemplateData is important Thingofme (talk) 14:21, 4 February 2022 (UTC)
  •   Support SlowByte (talk) 18:48, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 20:38, 4 February 2022 (UTC)
  •   Support Daniel Case (talk) 23:09, 5 February 2022 (UTC)
  •   Strong support I do this (opening multiple items with the same name) all the time. Automated descriptions in the style of Autodesc would be a great help. Waldyrious (talk) 00:36, 6 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 09:22, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:39, 6 February 2022 (UTC)
  •   Support Newt713 (talk) 13:45, 6 February 2022 (UTC)
  •   Support Giodiani (talk) 15:36, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 03:59, 7 February 2022 (UTC)
  •   Support Rzuwig 12:45, 7 February 2022 (UTC)
  •   Support Matthew T Rader (talk) 20:55, 7 February 2022 (UTC)
  •   Support Dipsacus fullonum (talk) 23:55, 10 February 2022 (UTC)

Custom edit summaries

  • Problem: Wikidata users should be able to provide custom edit summaries in GUI and special pages.
  • Proposed solution:
  • Who would benefit:
  • More comments: This is a very long-time issue first proposed in 2013.
  • Phabricator tickets: phab:T47224
  • Proposer: GZWDer (talk) 09:34, 21 January 2022 (UTC)

Discussion

Voting

  •   Support This can be done already if you edit by bot, but not if you're using the interface, would be good to have the option somehow. Thanks. Mike Peel (talk) 18:50, 28 January 2022 (UTC)
  •   Support Mahir256 (talk) 18:55, 28 January 2022 (UTC)
  •   Support * Pppery * it has begun 18:57, 28 January 2022 (UTC)
  •   Support Simeon (talk) 19:10, 28 January 2022 (UTC)
  •   Support Envlh (talk) 20:18, 28 January 2022 (UTC)
  •   Support Strainu (talk) 21:33, 28 January 2022 (UTC)
  •   Support — Draceane talkcontrib. 22:24, 28 January 2022 (UTC)
  •   Support Sgd. —Hasley 23:21, 28 January 2022 (UTC)
  •   Support Ottawajin (talk) 04:09, 29 January 2022 (UTC)
  •   Support SCIdude (talk) 07:56, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:49, 29 January 2022 (UTC)
  •   Support--Alexmar983 (talk) 21:14, 29 January 2022 (UTC)
  •   Support Douglasfugazi (talk) 21:20, 29 January 2022 (UTC)
  •   Support Ameisenigel (talk) 09:23, 30 January 2022 (UTC)
  •   Support«« Man77 »» [de] 13:52, 30 January 2022 (UTC)
  •   Support Wikiwerner (talk) 17:03, 30 January 2022 (UTC)
  •   Support Libcub (talk) 00:03, 31 January 2022 (UTC)
  •   Support FenyMufyd (talk) 10:46, 31 January 2022 (UTC)
  •   Support Hb2007 (talk) 15:25, 31 January 2022 (UTC)
  •   Support Labdajiwa (talk) 03:15, 1 February 2022 (UTC)
  •   Support Susanna Giaccai (talk) 10:32, 1 February 2022 (UTC)
  •   Support KAMEDA, Akihiro (talk) 12:09, 1 February 2022 (UTC)
  •   Support Thibaut (talk) 16:05, 1 February 2022 (UTC)
  •   Support PhiH (talk) 16:53, 1 February 2022 (UTC)
  •   Support This looks very useful, especially if you want to add context to your edits when needed. Example: I'm doing this way to try to achieve that. This cannot always be done through other properties because they might be lacking or users might not be aware of them. GNUtoo (talk) 21:47, 1 February 2022 (UTC)
  •   Support Sjkim04 (talk) 01:21, 3 February 2022 (UTC)
  •   Support --MarieVirtuElle (talk) 01:53, 3 February 2022 (UTC)
  •   Support Thingofme (talk) 14:27, 4 February 2022 (UTC)
  •   Support SlowByte (talk) 18:47, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 21:35, 4 February 2022 (UTC)
  •   Support Pi.1415926535 (talk) 22:15, 4 February 2022 (UTC)
  •   Support Mogador (talk) 03:17, 5 February 2022 (UTC)
  •   Support Lutzto (talk) 17:16, 5 February 2022 (UTC)
  •   Support SashiRolls (talk) 20:14, 5 February 2022 (UTC)
  •   Support Waldyrious (talk) 00:41, 6 February 2022 (UTC)
  •   Support Toadspike (talk) 03:20, 6 February 2022 (UTC)
  •   Support --Tinker Bell 06:27, 6 February 2022 (UTC)
  •   Support--Vulp❯❯❯here! 09:22, 6 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:15, 6 February 2022 (UTC)
  •   Support Newt713 (talk) 13:48, 6 February 2022 (UTC)
  •   Support --Luan (discussão) 14:43, 6 February 2022 (UTC)
  •   Support Redalert2fan (talk) 14:51, 6 February 2022 (UTC)
  •   Support GeoffreyT2000 (talk) 15:13, 6 February 2022 (UTC)
  •   Oppose --Ciao • Bestoernesto 16:50, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:06, 7 February 2022 (UTC)
  •   Support Lectrician1 (talk) 05:26, 6 February 2022 (UTC)
  •   Support Rzuwig 12:46, 7 February 2022 (UTC)
  •   Support Heanor (talk) 13:29, 8 February 2022 (UTC)
  •   Support paul2520 (talk) 16:51, 8 February 2022 (UTC)
  •   Support Suonii180 (talk) 19:54, 8 February 2022 (UTC)
  •   Support β16 - (talk) 09:40, 9 February 2022 (UTC)
  •   Support Marcok (talk) 07:28, 10 February 2022 (UTC)
  •   SupportDaxServer (t · c) 14:50, 10 February 2022 (UTC)
  •   Support Helder 22:04, 10 February 2022 (UTC)
  •   Support Dajasj (talk) 14:27, 11 February 2022 (UTC)
  •   Support Already possible for bots/APIs. Why not. Valerio Bozzolan (talk) 17:20, 11 February 2022 (UTC)

Multilingual dictionary GUI using Wikidata lexemes