Community Wishlist Survey 2022/Wikidata
Do not follow sitelink redirects when redirect badge is used
- Problem: 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):
- 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)
- 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
- 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:
- 2015: Community Wishlist Survey 2015/Wikidata#Allow Redirects to be linked to Wikidata items (9 votes)
- 2017–2018: d:Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata (93 / 33 votes)
- 2020: Community Wishlist Survey 2021/Wikidata/Link Wikipedia redirects to Wikidata items (65 votes)
- 2020: d:Wikidata:Requests for comment/Adopt Help:SitelinksToRedirects as policy (9 / 1 votes)
- 2021: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages (phab:T235420) task resolved
- 2021: do not follow sitelink redirects when redirect badge is used (phab:T278962) task was created and the work started, but apparently abandoned
- 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)
- "intentional redirect" (
- 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)
- (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
- 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)
- 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)
- Support — putnik 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 Liu(Talk) 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)
- Support — DaxServer (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
- Support Jklamo (talk) 18:44, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 22:23, 28 January 2022 (UTC)
- Support Ottawajin (talk) 04:45, 29 January 2022 (UTC)
- Support JakobVoss (talk) 07:32, 29 January 2022 (UTC)
- Support OwenBlacker (Talk) 11:35, 30 January 2022 (UTC)
- Support Silver hr (talk) 20:33, 2 February 2022 (UTC)
- Support Thingofme (talk) 14:20, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 20:27, 4 February 2022 (UTC)
- Support Kpjas (talk) 13:17, 5 February 2022 (UTC)
- Support Exilexi (talk) 18:06, 5 February 2022 (UTC)
- Support--Vulp❯❯❯here! 09:22, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 10:27, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:35, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 04:07, 7 February 2022 (UTC)
- Support Marcok (talk) 07:30, 10 February 2022 (UTC)
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 inP:
, 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
- Support I really like this idea and it sounds like it wouldn't be too costly to implement. To please the naysayers, maybe it could be made optional, as a setting under Preferences ? Moebeus (talk) 18:33, 28 January 2022 (UTC)
- Support Jklamo (talk) 18:40, 28 January 2022 (UTC)
- Support Simeon (talk) 18:54, 28 January 2022 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:19, 28 January 2022 (UTC)
- Support These properties are so confusing to new community members Wskent (talk) 19:58, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 22:27, 28 January 2022 (UTC)
- Support - PKM (talk) 23:06, 28 January 2022 (UTC)
- Support Izno (talk) 00:11, 29 January 2022 (UTC)
- Support Higa4 (talk) 06:22, 29 January 2022 (UTC)
- Support JopkeB (talk) 07:06, 29 January 2022 (UTC)
- Support Agreed that these Wikimedia-specific properties should be grouped and displayed separately in the web UI. Dhx1 (talk) 07:08, 29 January 2022 (UTC)
- Support JakobVoss (talk) 07:35, 29 January 2022 (UTC)
- Support Aca (talk) 15:47, 29 January 2022 (UTC)
- Support ♥Ainali talkcontributions 15:48, 29 January 2022 (UTC)
- Support for the same reasons stated in the discussion. Alexmar983 (talk) 18:03, 29 January 2022 (UTC)
- Support --Epìdosis 20:58, 29 January 2022 (UTC)
- Support josecurioso ❯❯❯ Tell me! 00:46, 30 January 2022 (UTC)
- Support Wostr (talk) 01:02, 30 January 2022 (UTC)
- Support Pelagic (talk) 09:26, 30 January 2022 (UTC)
- Support OwenBlacker (Talk) 11:42, 30 January 2022 (UTC)
- Support Wotheina (talk) 17:38, 30 January 2022 (UTC)
- Support Lectrician1 (talk) 19:03, 30 January 2022 (UTC)
- Support Ariadacapo (talk) 10:25, 31 January 2022 (UTC)
- Support Sannita - not just another it.wiki sysop 12:05, 31 January 2022 (UTC)
- Support JAn Dudík (talk) 21:33, 31 January 2022 (UTC)
- Support Susanna Giaccai (talk) 10:38, 1 February 2022 (UTC)
- Support Geert Van Pamel (WMBE) (talk) 15:58, 2 February 2022 (UTC)
- Support Silver hr (talk) 21:06, 2 February 2022 (UTC)
- Support --MarieVirtuElle (talk) 01:59, 3 February 2022 (UTC)
- Support Paucabot (talk) 16:10, 3 February 2022 (UTC)
- Support Thingofme (talk) 14:30, 4 February 2022 (UTC)
- Support Kpjas (talk) 13:28, 5 February 2022 (UTC)
- Support Wintercake93 (talk) 16:22, 5 February 2022 (UTC)
- Support Waldyrious (talk) 00:46, 6 February 2022 (UTC)
- Support--Vulp❯❯❯here! 09:22, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 10:16, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 03:59, 7 February 2022 (UTC)
- Support Rzuwig► 12:45, 7 February 2022 (UTC)
- Support ~Cybularny Speak? 23:49, 9 February 2022 (UTC)
- Support — DaxServer (t · c) 12:31, 10 February 2022 (UTC)
- Support Dipsacus fullonum (talk) 23:41, 10 February 2022 (UTC)
- Support Gaurav (talk) 06:53, 11 February 2022 (UTC)
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
- Support —The 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:
- PropertySuggester should (i) also suggest values; (ii) suggest meaningful items for units.
- Commons Structured Data also need a PropertySuggester implementation
)
- Who would benefit:
- More comments:
- Phabricator tickets: phab:T111154, phab:T244856, phab:T229990; also (specific cases to improve) phab:T173406, phab:T132839
- Proposer: GZWDer (talk) 21:36, 22 January 2022 (UTC)
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
- Support Moebeus (talk) 18:58, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 22:27, 28 January 2022 (UTC)
- Support Siddhant (talk) 11:07, 29 January 2022 (UTC)
- Support Nw520 (talk) 23:23, 29 January 2022 (UTC)
- Support Silver hr (talk) 19:46, 2 February 2022 (UTC)
- Support Thingofme (talk) 14:24, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 19:15, 4 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:47, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 03:57, 7 February 2022 (UTC)
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
- Support Yes, please! — Draceane talkcontrib. 22:20, 28 January 2022 (UTC)
- Support Dhx1 (talk) 07:18, 29 January 2022 (UTC)
- Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:30, 29 January 2022 (UTC)
- Support Lectrician1 (talk) 18:49, 29 January 2022 (UTC)
- Support Douglasfugazi (talk) 21:20, 29 January 2022 (UTC)
- Support Nw520 (talk) 23:24, 29 January 2022 (UTC)
- Support Matěj Suchánek (talk) 11:30, 30 January 2022 (UTC)
- Support Jmaxx37 (talk) 18:41, 30 January 2022 (UTC)
- Support JAn Dudík (talk) 21:30, 31 January 2022 (UTC)
- Support Wargo (talk) 22:43, 1 February 2022 (UTC)
- Support Krol111 (talk) 20:58, 2 February 2022 (UTC)
- Support Thingofme (talk) 14:22, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 19:56, 4 February 2022 (UTC)
- Support ·addshore· talk to me! 23:11, 4 February 2022 (UTC)
- Support Daniel Case (talk) 23:12, 5 February 2022 (UTC)
- Support Waldyrious (talk) 00:42, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 10:38, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:41, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 04:05, 7 February 2022 (UTC)
- Support Helder 22:03, 10 February 2022 (UTC)
- Support Meiræ 22:20, 10 February 2022 (UTC)
- Support Dipsacus fullonum (talk) 00:14, 11 February 2022 (UTC)
- Support Wikisaurus (talk) 14:29, 11 February 2022 (UTC)
- Support Searching the Property and Lexeme namespace requires performing searches using the prefixes "Property:" and "Lexeme:", there's no out-of-the-box way to search as it is possible to do using the search bar with Wikidata Items. Rdrg109 (talk) 15:04, 11 February 2022 (UTC)
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)- @Saippuakauppias: Thank you, but that is not how references work, on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:59, 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)
- Oppose — DaxServer (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 Liu(Talk) 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)
- Support — DaxServer (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
- Problem: The problem of connecting newly created articles to existing objects respectivley creating new objects for unconnected pages (when, how, by whom, ...) for hundreds of newly created articles per day in different language versions, and how to avoid duplicates amongst the currently 96 million objects d:Special:Statistics, has been discussed for years again and again without a real solution, for example at d:Wikidata:Requests for permissions/Bot/RegularBot 2
- Proposed solution: At d:Wikidata:Contact_the_development_team/Archive/2020/09#Connecting newly created articles to existing objects resp. creating new object - additional step when creating articles, categories, etc. a possible solution has been discussed:
An additional step after saving a newly created article etc. to present to the user a list of possible matching wikidata objects (e.g. a list of persons with the same name; could be a similar algorithm as the duplicate check / suggestion list in PetScan, duplicity example) or the option to create a new object if no one matches (depending one the type of the object, some values could be already be pre-filled and pulled from the article, e.g. from categories or infoboxes). From my point of view, one current problem is, that a lot of creators of articles, categories, navigational items, templates, disambiguations, lists, commonscats, etc. are either not aware of the existance of wikidata or did forget to connect a newly created article etc. to an already existing object or to create a new one if not yet existing, which might lead to (more) duplicates, if this creation respectivley connection is not done manually, but by a bot instead, which have to be merged manually afterwards.
In addition, there could be specialized (depending on the type of the objects, e.g. one bot for humans, one for films, one for building, etc.) bots, which are for example able to check for various IDs (like GND, VIAF, LCCN, IMDb, ...) in order to avoid creating duplicates and creates new items or connects matching items based on IDs.
Also, if someone uses the "translation function" to create a translated article in another language version, then the new translated article could be connected automatically to the object of the original article. And after a version import (after a translation), at the moment often the link to the Wikidata object gets lost and the article has to be reconnected again a second time manually.
- Who would benefit: Improved data quality, i.e. less duplicates
- More comments: Also see:
- Community Wishlist Survey 2021/Wikidata/Creation of new objects resp. connecting to existing objects while avoiding duplicates
- de:Wikipedia:Technische_Wünsche/Wunschparkplatz#Verbinden/Anlegen_von_bestehenden/neuen_Wikidata-Objekten_mit_neu_angelegten_Artikeln/Kategorien_unter_Vermeidung_von_Dubletten
- Phabricator tickets:
- Proposer: --M2k~dewiki (talk) 18:17, 10 January 2022 (UTC)
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)
This wish has a project page. Please consult it for development updates. –– STei (WMF) (talk) 10:54, 24 April 2024 (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
- Support Jklamo (talk) 18:46, 28 January 2022 (UTC)
- Support Adding sitelinks to new articles is a huge problem that this would significantly help with. Thanks. Mike Peel (talk) 18:51, 28 January 2022 (UTC)
- Support Simeon (talk) 19:12, 28 January 2022 (UTC)
- Support Bluerasberry (talk) 19:52, 28 January 2022 (UTC)
- Support --Arnd (talk) 20:19, 28 January 2022 (UTC)
- Support CLalgo (talk) 22:02, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 22:23, 28 January 2022 (UTC)
- Support --Kusurija (talk) 22:30, 28 January 2022 (UTC)
- Support Jheald (talk) 23:27, 28 January 2022 (UTC)
- Support Betseg (talk) 02:25, 29 January 2022 (UTC)
- Support Ottawajin (talk) 04:46, 29 January 2022 (UTC)
- Support Higa4 (talk) 06:25, 29 January 2022 (UTC)
- Support JopkeB (talk) 07:08, 29 January 2022 (UTC)
- Support Dhx1 (talk) 07:10, 29 January 2022 (UTC)
- Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:28, 29 January 2022 (UTC)
- Support Afernand74 (talk) 09:01, 29 January 2022 (UTC)
- Support Siddhant (talk) 11:08, 29 January 2022 (UTC)
- Support — মো সোহানুর রহমান (talk) 11:50, 29 January 2022 (UTC)
- Support --Spiros71 (talk) 13:16, 29 January 2022 (UTC)
- Support NguoiDungKhongDinhDanh 13:22, 29 January 2022 (UTC)
- Support Smasongarrison (talk) 13:48, 29 January 2022 (UTC)
- Support HLFan (talk) 15:44, 29 January 2022 (UTC)
- Support Aca (talk) 15:46, 29 January 2022 (UTC)
- Support Mbrickn (talk) 16:23, 29 January 2022 (UTC)
- Support daSupremo 17:02, 29 January 2022 (UTC)
- Support Saliousoft (talk) 17:39, 29 January 2022 (UTC)
- Support --Epìdosis 21:00, 29 January 2022 (UTC)
- Support Douglasfugazi (talk) 21:20, 29 January 2022 (UTC)
- Support josecurioso ❯❯❯ Tell me! 00:47, 30 January 2022 (UTC)
- Support Lectrician1 (talk) 07:27, 30 January 2022 (UTC)
- Support Ameisenigel (talk) 09:24, 30 January 2022 (UTC)
- Support The search should consider other similarities besides names of sitelinks, such as which existing articles, images, external references or categories (excluding catch-all categories with hundreds of unrelated pages) the new article links to. If the new article has no links yet and no suitable matching name, I would recommend postponing creation of the new Wikidata item. SM5POR (talk) 10:20, 30 January 2022 (UTC)
- Support --Amadalvarez (talk) 14:17, 30 January 2022 (UTC)
- Support Titore (talk) 18:51, 30 January 2022 (UTC)
- Support Qwerfjkl (talk) 19:53, 30 January 2022 (UTC)
- Support Libcub (talk) 23:58, 30 January 2022 (UTC)
- Support JPxG (talk) 01:04, 31 January 2022 (UTC)
- Support JAn Dudík (talk) 09:18, 31 January 2022 (UTC)
- Support Ariadacapo (talk) 10:21, 31 January 2022 (UTC)
- Support FenyMufyd (talk) 11:39, 31 January 2022 (UTC)
- Support Sannita - not just another it.wiki sysop 12:07, 31 January 2022 (UTC)
- Support Hb2007 (talk) 15:25, 31 January 2022 (UTC)
- Support Simple and logical proposal to fix a continuing problem. ArthurPSmith (talk) 15:50, 31 January 2022 (UTC)
- Support Bencemac (talk) 18:07, 31 January 2022 (UTC)
- Support Daud Iffa (talk) 22:38, 31 January 2022 (UTC)
- Support Labdajiwa (talk) 03:15, 1 February 2022 (UTC)
- Support H78c67c (talk) 04:14, 1 February 2022 (UTC)
- Support Z423x5c6 (talk) 05:20, 1 February 2022 (UTC)
- Support --Alaa :)..! 08:29, 1 February 2022 (UTC)
- Support KAMEDA, Akihiro (talk) 12:14, 1 February 2022 (UTC)
- Support Bietels (talk) 14:38, 2 February 2022 (UTC)
- Support Geert Van Pamel (WMBE) (talk) 15:45, 2 February 2022 (UTC)
- Support Silver hr (talk) 20:04, 2 February 2022 (UTC)
- Support Krol111 (talk) 20:59, 2 February 2022 (UTC)
- Support --MarieVirtuElle (talk) 01:51, 3 February 2022 (UTC)
- Support Example for the pop up; also see Community_Wishlist_Survey_2022/Wikidata/Creation_of_new_objects_resp._connecting_to_existing_objects_while_avoiding_duplicates; --M2k~dewiki (talk) 06:37, 3 February 2022 (UTC)
- Support Rotavdrag (talk) 11:09, 3 February 2022 (UTC)
- Support Giacomo Alessandroni let's talk! 14:54, 3 February 2022 (UTC)
- Support Paucabot (talk) 16:06, 3 February 2022 (UTC)
- Support Thingofme (talk) 14:24, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 20:42, 4 February 2022 (UTC)
- Support Dave Braunschweig (talk) 23:45, 4 February 2022 (UTC)
- Support Kpjas (talk) 13:31, 5 February 2022 (UTC)
- Support Great idea! Pdreijnders (talk) 16:46, 5 February 2022 (UTC)
- Support Lutzto (talk) 17:26, 5 February 2022 (UTC)
- Support Ealdgyth (talk) 17:52, 5 February 2022 (UTC)
- Support --Rita2008 (talk) 17:53, 5 February 2022 (UTC)
- Support Exilexi (talk) 18:06, 5 February 2022 (UTC)
- Support So long as the autosuggest did not encourage Wikipedia creators to select inaccurate matches (such as confusing an address entry with a building entry which has the same name). Inaccurate linking would surely reduce quality/value for everyone, and lead to more cleanup work being required. Bobulous (talk) 19:24, 5 February 2022 (UTC)
- Support Daniel Case (talk) 23:06, 5 February 2022 (UTC)
- Support--Vulp❯❯❯here! 09:22, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 10:47, 6 February 2022 (UTC)
- Support--Kowlooner (talk) 13:55, 6 February 2022 (UTC)
- Support I am a man (talk) 14:02, 6 February 2022 (UTC)
- Support Redalert2fan (talk) 14:51, 6 February 2022 (UTC)
- Oppose I agree with the idea, but if Wikimedia Enterprise team is in it already then it's probably for the best to let them handle it.C933103 (talk) 16:23, 6 February 2022 (UTC)
- Oppose --Ciao • Bestoernesto • ✉ 16:43, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 04:01, 7 February 2022 (UTC)
- Support Rzuwig► 12:18, 7 February 2022 (UTC)
- Support ChimMAG (talk) 12:36, 7 February 2022 (UTC)
- Support Vincent Vega msg? 12:37, 7 February 2022 (UTC)
- Support Tom Ja (talk) 18:19, 7 February 2022 (UTC)
- Support CrystalBlacksmith (talk) 03:32, 8 February 2022 (UTC)
- Support paul2520 (talk) 16:49, 8 February 2022 (UTC)
- Support Suonii180 (talk) 17:30, 8 February 2022 (UTC)
- Support BugWarp (talk) 00:27, 9 February 2022 (UTC)
- Support Bodhisattwa (talk) 09:38, 9 February 2022 (UTC)
- Support ~Cybularny Speak? 23:47, 9 February 2022 (UTC)
- Support Marcok (talk) 07:27, 10 February 2022 (UTC)
- Support katpatuka (talk) 08:46, 10 February 2022 (UTC)
- Support — DaxServer (t · c) 14:51, 10 February 2022 (UTC)
- Support Hroptatyr (talk) 05:57, 11 February 2022 (UTC)
- Support 4nn1l2 (talk) 12:58, 11 February 2022 (UTC)
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
- Support MER-C 18:17, 28 January 2022 (UTC)
- Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:32, 29 January 2022 (UTC)
- Support Aca (talk) 15:52, 29 January 2022 (UTC)
- Support daSupremo 17:07, 29 January 2022 (UTC)
- Support Douglasfugazi (talk) 21:18, 29 January 2022 (UTC)
- Support Libcub (talk) 23:56, 30 January 2022 (UTC)
- Support Seini.coe (talk) 18:05, 2 February 2022 (UTC)
- Support Very much needed DannyS712 (talk) 03:09, 3 February 2022 (UTC)
- Support It is protecting the title like the title blacklist protection Thingofme (talk) 14:19, 4 February 2022 (UTC)
- Support Daniel Case (talk) 23:05, 5 February 2022 (UTC)
- Support —— Eric Liu(Talk) 10:39, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:52, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 04:09, 7 February 2022 (UTC)
- Support β16 - (talk) 09:44, 9 February 2022 (UTC)
- Support — DaxServer (t · c) 14:49, 10 February 2022 (UTC)
- Support Martinligabue (talk) 14:01, 11 February 2022 (UTC)
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
- Support Mahir256 (talk) 18:38, 28 January 2022 (UTC)
- Support --Arnd (talk) 20:18, 28 January 2022 (UTC)
- Support --Epìdosis 20:53, 29 January 2022 (UTC)
- Support--Alexmar983 (talk) 21:09, 29 January 2022 (UTC)
- Support Nw520 (talk) 23:22, 29 January 2022 (UTC)
- Support --Amadalvarez (talk) 14:13, 30 January 2022 (UTC)
- Support Wargo (talk) 22:43, 1 February 2022 (UTC)
- Support Thingofme (talk) 14:29, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 21:30, 4 February 2022 (UTC)
- Support Kpjas (talk) 13:39, 5 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:38, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 04:07, 7 February 2022 (UTC)
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:
- Create the property with the proper label/description
- Copy the information from the template to the newly created property
- Modify the template with the property number
- 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)
- 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)
- 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
- Support Ottawajin (talk) 04:02, 29 January 2022 (UTC)
- Support Lectrician1 (talk) 04:45, 29 January 2022 (UTC)
- Support Douglasfugazi (talk) 21:18, 29 January 2022 (UTC)
- Support Ali Imran Awan (talk) 07:19, 30 January 2022 (UTC)
- Support Malexan (talk) 13:28, 30 January 2022 (UTC)
- Support Silver hr (talk) 20:28, 2 February 2022 (UTC)
- Support Giacomo Alessandroni let's talk! 14:52, 3 February 2022 (UTC)
- Support Good idea! Thingofme (talk) 14:29, 4 February 2022 (UTC)
- Support ·addshore· talk to me! 23:06, 4 February 2022 (UTC)
- Support Daniel Case (talk) 23:04, 5 February 2022 (UTC)
- Support —— Eric Liu(Talk) 10:37, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:42, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 04:08, 7 February 2022 (UTC)
- Support paul2520 (talk) 16:46, 8 February 2022 (UTC)
- Support Marcok (talk) 07:36, 10 February 2022 (UTC)
- Support Meiræ 22:24, 10 February 2022 (UTC)
- Support Gaurav (talk) 06:55, 11 February 2022 (UTC)
- Support Martinligabue (talk) 14:03, 11 February 2022 (UTC)
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)
- Thank you @AllyD: and @SWilson (WMF):! To clarify my suggestion, I made a picture of it : https://imgur.com/a/3WVDqwy. Regards! Pmartinolli (talk) 14:50, 20 January 2022 (UTC)
- @Pmartinolli: Thanks, that looks great! SWilson (WMF) (talk) 23:55, 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 Liu(Talk) 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
- Related to Community_Wishlist_Survey_2022/Wikidata/Do_not_follow_sitelink_redirects_when_redirect_badge_is_used. --Izno (talk) 20:10, 18 January 2022 (UTC)
Voting
- Support Jklamo (talk) 18:45, 28 January 2022 (UTC)
- Support Thanks. Mike Peel (talk) 18:49, 28 January 2022 (UTC)
- Support Strainu (talk) 21:26, 28 January 2022 (UTC)
- Support 5225C (talk • contributions) 01:13, 29 January 2022 (UTC)
- Support See also Community Wishlist Survey 2021/Wikidata/Link Wikipedia redirects to Wikidata items. Certes (talk) 02:00, 29 January 2022 (UTC)
- Support This is a common issue that should be resolved as expeditiously as possible to help guide Wikidata's growth. {{u|Sdkb}} talk 03:49, 29 January 2022 (UTC)
- Support SCIdude (talk) 07:54, 29 January 2022 (UTC)
- Support Siddhant (talk) 11:10, 29 January 2022 (UTC)
- Support Aca (talk) 15:48, 29 January 2022 (UTC)
- Support daSupremo 17:05, 29 January 2022 (UTC)
- Support (as the other one). --Epìdosis 21:02, 29 January 2022 (UTC)
- Support josecurioso ❯❯❯ Tell me! 00:46, 30 January 2022 (UTC)
- Support See also strong support at d:Requests_for_comment/Allow_the_creation_of_links_to_redirects_in_Wikidata--Fano (talk) 08:47, 30 January 2022 (UTC)
- Support Ameisenigel (talk) 09:25, 30 January 2022 (UTC)
- Support Qwerfjkl (talk) 19:37, 30 January 2022 (UTC)
- Support --Hsarrazin (talk) 07:04, 31 January 2022 (UTC)
- Support Uanfala (talk) 13:28, 31 January 2022 (UTC)
- Support ArthurPSmith (talk) 15:56, 31 January 2022 (UTC)
- Support JAn Dudík (talk) 21:32, 31 January 2022 (UTC)
- Support SM5POR (talk) 07:30, 1 February 2022 (UTC)
- Support Silver hr (talk) 20:05, 2 February 2022 (UTC)
- Support Aimwin66166 (talk) 06:05, 3 February 2022 (UTC)
- Support Thingofme (talk) 14:21, 4 February 2022 (UTC)
- Support Pi.1415926535 (talk) 22:14, 4 February 2022 (UTC)
- Support Kpjas (talk) 13:23, 5 February 2022 (UTC)