Jump to content

Community Wishlist Survey 2023/Wikidata

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2023
Wikidata
14 proposals, 245 contributors, 547 support votes
The survey has closed. Thanks for your participation :)



Prevent data duplication

Discussion

Voting

More languages for editing label

  • Problem: When editing a label, only a few preselected languages appear. Finding how to choose these available languages in a pain (I found it once somewhere in the options, but I could not find it anymore).
  • Proposed solution: When editing the label, add a button "Add more languages" or "Edit languages" under the few preselected languages.
  • Who would benefit: People who edit in several languages.
  • More comments:
  • Phabricator tickets: phab:T126510
  • Proposer: Sovxx (talk) 13:13, 29 January 2023 (UTC)[reply]

Discussion

Voting

Scientific papers: Sort authors by their own rank

  • Problem: Sometimes the article is created with only authors with the property P2093 (only text without link), then some of them (all at the end...) are transfered to the property P50 (link to the good author page) but the authors are showned in the order of their addition to the page not to their own rank (P1545). It will be better, especially when there is a lot of authors, to have a sorting by this property. See for example this page with 14 authors currently showned as 2; 7; 1; 3; 5; 6; 9; 10; 11; 12; 13; 14 - and the last ones on the right order because I added by. [Sorry for my poor english!]
  • Proposed solution: Add a sorting on the P1545 property for the field P50 and an another one for the field P2093.
  • Who would benefit:
  • More comments:
  • Phabricator tickets: T173432
  • Proposer: Givet (talk) 10:21, 24 January 2023 (UTC)[reply]

Discussion

Voting

Popup to link to or create a new Wikidata item after creating an article

  • 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 105 million objects, 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, see for example this 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.

    This pop-up should be presented for:

    • newly created articles in the article namespace
    • articles that have been moved from user/draft namespace to article namespace
    • articles, that have been expanded from a redirect
    • newly created categories
In addition, there could be specialized (depending on the type of the objects, e.g. one bot for humans, one for films, one for buildings, etc.) bots, which are for example able to check for various IDs (like GND, VIAF, LCCN, IMDb, monument-IDs ...) 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.

Also see:

and

Statistics of unconnected articles:


This wish now has a project page. Please consult it for development updates. –– STei (WMF) (talk) 10:50, 24 April 2024 (UTC)[reply]

Discussion

See also another idea on linking new pages to Wikidata items: phab:T178249. — putnik 22:05, 23 January 2023 (UTC)[reply]
  • How would this work for non-Wikipedia projects? Wikisource items are editions of specific works, that have their own publication data, and they usually should not be added to any existing Wikidata item because they have their own publication data (specific to that edition) that needs to be recorded in a data item for that edition. Would this pop-up recognize the difference between needing a Wikidata item for an edition (specific to Wikidata and to the scan of that edition on Commons) versus a Wikidata item for the work itself, which would link to Wikipedia articles, Commons Categories (not scans), and Wikiquote? Or will the pop-up look for closely-matching items regardless of these issues? The very fact that this proposal is about "articles" shows that it doesn't consider the issues inherent with non-Wikipedia projects. --EncycloPetey (talk) 20:16, 23 January 2023 (UTC)[reply]
This functionality could be available on a project base respectivley on a language base, so every community of every project and language version could decide, if this feature should be (de)activated. --M2k~dewiki (talk) 20:42, 23 January 2023 (UTC)[reply]
That response does not address the problem I raised. If Wikipedia has it active, but they are adding links for works to editions items, that's a problem, because Wikipedia is then adding information incorrectly to data items. Likewise, if a Wikisource has this active, but it puts links for an edition into a work data item, then it's added the information incorrectly. If English Wikisource has this active, and it causes English edition links for an English edition to be added to a data item for a French edition, then the information has been added incorrectly. Your response does not address these issues. --EncycloPetey (talk) 16:08, 25 January 2023 (UTC)[reply]
Editions could be filtered out in the result sets presented by for example duplicity: https://wikidata-todo.toolforge.org/duplicity.php?wiki=dewiki&norand=1&page=Vasco%5FCordeiro --M2k~dewiki (talk) 16:12, 25 January 2023 (UTC)[reply]
Then how would links be added if the desired target is to be an edition? If it is information for a specific publication, then it's an edition. 99% of data items for Wikisource projects are editions. When a published reference is to be cited, it's a specific edition. And the example link you provided makes no sense in terms of the context of this discussion. Do you understand the difference between a work and an edition? --EncycloPetey (talk) 16:20, 25 January 2023 (UTC)[reply]
  • I've merged "Add interlanguage links" interface should let users input sister wiki pages into this proposal, because it looks like both can be solved with a system of presenting possible existing Wikidata items (and optionally creating a new one with the sitelink already added). These tasks are what the AutosuggestSitelink gadget is aiming to solve, so I'd suggest that we'd look at adding any missing functionality there. For example, when creating a new Wikisource edition page, often there is no item for the edition but we could prompt to find the appropriate work item and if one exists create the edition item with all links as appropriate. (Details t.b.d. of course! Hopefully I'm not handwaving away something impossible there.) SWilson (WMF) (talk) 07:17, 1 February 2023 (UTC)[reply]
Tracked in Phabricator:
Task T308059


Voting

Improve handling of dates in languages other than English

Discussion

  • As I was told, phab:T221097 should be fixed in the following days. The bugfix only concerns parsing, though. --Matěj Suchánek (talk) 14:11, 5 February 2023 (UTC)[reply]
  • Long-standing problem. I can just add two personal experiences with Italian interface: it parses months with lowercase initial (e.g. 22 marzo 2022) but not with less common (but sometimes used) uppercase initial (e.g. 22 Marzo 2022); since in Italy the most-common usage is dd mm yyyy, I can say that dd-mm-yyyy and dd mm yyyy are interpreted correctly, whilst dd/mm/yyyy is interpreted wrongly as mm/dd/yyyy (which can cause errors, if the user doesn't notice the problem when saving). I think this inversion of month and day is a problem perceived also in other languages: probably, in ambiguous cases (e.g. 01/02/2022), the system should just present the two options to the user and ask them to choose, in order to avoid misinterpretations. --Epìdosis 18:46, 5 February 2023 (UTC)[reply]
  • + phab:T167788 Ayack (talk) 08:22, 13 February 2023 (UTC)[reply]
  • It is likely a super challenge (a pipe dream) asking for an ability to translate dates from lunisolar calendar to the Gregorian system. It is an unfortunate task for editors who tried to decipher dates from a primary source that deployed an emperor's era. For instance,"清高宗乾隆丁亥四月十九日" (transliteration: Qing Gaozong Qianlong Ding hai si yue shijiu ri; translated to Gaozong of Qing, Qianlong Emperor, 32nd year, 4th month, 19th day) to the Gregorian date, 1767 May 16. Nevertheless, if somehow a system could push forward a year, such as 民國一百一十二年 (minguo 112) to 2023. That would be a great start! Is that even possible? Thank you. ShiehJ (talk) 19:39, 15 February 2023 (UTC)[reply]
    That is part of another wish, https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Wikidata/Support_for_non-Gregorian_and_non-Julian_calendar_models_on_Wikidata C933103 (talk) 12:09, 5 March 2023 (UTC)[reply]
  • For everyone following this discussion, there is an upcoming Bug Triage Hour on dates input that may be of interest to you all. On March 13th, we will be following up on an issue with date parsing in the Czech language (T221097) that was fixed in February. During the Bug Triage Hour, we will be looking at the changes induced by this fix together, checking how the date input parsing works in different languages, and identifying any possibly remaining issues. This may be a great opportunity for those concerned with the handling of dates in languages other than English to get involved and provide feedback. -Mohammed Sadat (WMDE) (talk) 10:39, 6 March 2023 (UTC)[reply]

Voting

Ability to reorder statements

  • Problem: Wikidata statements for the same property are shown in the order they are added to Wikidata. In many cases, there's a natural order that can derivate from the order in which the statements were added.

    A user that wants to fix the order has to delete and recreate the statement which is undesirable. While external data users can configure their scripts to use a property like "point in time" to order the statements, users within Wikidata have no way to order them.

  • Proposed solution: Add a feature that exchanges the position of two statements which use the same property within an item.
  • Who would benefit: All users who access items that are currently unordered directly within the Wikidata UI.
  • More comments:
  • Phabricator tickets: T173432
  • Proposer: ChristianKl ❪✉❫ 15:46, 24 January 2023 (UTC)[reply]

Discussion

Voting

Default collapse statements when they have many values

  • Problem: Some Wikidata items have a huge number of statements for some properties. A few examples are populations on human settlements and administrative areas (e.g. d:Q183#P1082), versions on software (e.g. d:Q83#P348) and number of deaths on COVID-19 items (e.g. d:Q87477462#P1120) but there are many more. This makes these items very tedious to navigate, as they require an excessive amount of scrolling. This was discussed on Wikidata four years ago, and resurfaced last fall (connected to a larger issue).
  • Proposed solution: If a statement has more than just a few values, perhaps even as low as three, the entire statement could be "collapsed" to just show the property name, how many values it has, and a way to expand it. A nice-to-have is if expanding a property is "remembered" across items, as it is not unusual to work on the same property on a number of items and repeatedly having to unfold it then also would be tedious. Also, since a small number of editors working on these kinds of properties might not want to have this behavior at all, it should be possible to turn it off in the preferences (or by turning off the gadget, if that is how it is implemented).
  • Who would benefit: Editors and readers of Wikidata.
  • More comments:
  • Phabricator tickets: Tickets:
  • Proposer: ♥Ainali talkcontributions 19:14, 29 January 2023 (UTC)[reply]

Discussion

Voting

Optional native language label language name

  • Problem: In the label box on Wikidata, all names are printed in Swedish, this bothers me a bit as I want to be able to read them in the native language instead, for example Deutsch instead of German, français instead of French, etc.
  • Proposed solution: Introducing the technical possibility to change the display language of the labels so that you can choose whether you want translated or native names on the labels
  • Who would benefit: People who mostly edit in a few languages and don't necessarily want to see them translated into the interface language.
  • More comments: See my other suggestions on how to improve the label list on Wikidata: Show Wikimedias language code and language name in Wikidata label box, Sort label box by language name on Wikidata
  • Phabricator tickets:
  • Proposer: Sabelöga (talk) 21:23, 23 January 2023 (UTC)[reply]

Discussion

Does this also include scripts? Thank you. ShiehJ (talk) 19:17, 15 February 2023 (UTC)[reply]

Voting

Show Wikimedias language code and language name in Wikidata label box

  • Problem: When using LabelLister or similar systems to add labels in new languages or want to find a specific language but don't want to go through 300+ languages, it can be useful to know by which language code the languages are sorted after all.
  • Proposed solution: Introduced the ability to print the languages' language code in the label box, preferably before the language name so that editors know what that language's language code is.
  • Who would benefit: Editors who contribute in multiple languages
  • More comments: See my other suggestions on how to improve the label list on Wikidata: Optional native language label language name, Sort label box by language name on Wikidata
  • Phabricator tickets:
  • Proposer: Sabelöga (talk) 23:02, 25 January 2023 (UTC)[reply]

Discussion

This is how it looks for me now: https://imgur.com/a/TyCp4Va. This is a mockup on how I want it to look: https://imgur.com/a/U7JeJgW.

Voting

Sort label box by language name on Wikidata

Discussion

Voting

Adding statements on mobile devices

  • Problem: On mobile devices it's only possible to add and edit interwikilinks, labels, descriptions and alias. But it's not possible to edit or add statements.
  • Proposed solution:
  • Who would benefit: Users, who:
    • don't have a PC available at any time
    • prefer to use mobile devices
  • More comments: This change would make editing Wikidata more accessible, time- and devices-independent. Previously proposed in the 2016 Wishlist Survey.
  • Phabricator tickets: T95878
  • Proposer: Yuriklim (talk) 10:58, 24 January 2023 (UTC)[reply]

Discussion

  • @Yuriklim: I fixed typo of the name page. Tryvix1509 (talk) 10:01, 24 January 2023 (UTC)[reply]
  • I strongly support this proposal. I mainly contribute to Wikidata and Wikipedia with my mobile phone. When editing Wikidata I switch between the web mobile interface (known as Minerva) to write wikitext, labels and interwiki links and the desktop interface (I use Timeless) to add statements. It's quite difficult. I think that something that half of the traffic on the Web comes from people using mobile devices. Those people should have a solution to quickly contribute to Wikidata. PAC2 (talk) 21:42, 24 January 2023 (UTC)[reply]
  • Strongly support. Would also support a separate Wikidata app, or the option to edit Wikidata in the existing Wikipedia app. CvZ (talk) 02:47, 29 January 2023 (UTC)[reply]
  • Like this idea. This will be help contributors to quickly add new information as soon as they find relevant information. John Samuel 18:34, 29 January 2023 (UTC)[reply]
  • This would be a great step forward. Robby (talk) 21:56, 29 January 2023 (UTC)[reply]
  • Yes. I often navigate by WikiShootMe to find photo targets and it isn't there, so I walk around and find the target, but entering the correct location is not really practical until I get home to the big computer. WD items and their statements are individually small and self contained, so they ought to be easily edited on small screen. ̴̃Jim.henderson (talk) 08:22, 19 February 2023 (UTC)[reply]

Voting

Support for non-Gregorian and non-Julian calendar models on Wikidata

  • Problem: Wikidata does not support calender models other than Gregorian and Julian, but there are a vast amount of data described in other calender models like Hijri, Hebrew, Bengali etc., which don't get incorporated into Wikidata.
  • Proposed solution: Provide a system to include other calender models so that users can input data accordingly.
  • Who would benefit: Non-Western communities who have data in these other calender models but have no option to include them in current system.
  • More comments:
  • Phabricator tickets: T252627
  • Proposer: Bodhisattwa (talk) 06:35, 31 January 2023 (UTC)[reply]

Discussion

Voting

Clickable map for coordinate locations

Discussion

  • Until something like this has been implemented, you might consider using the tool Wikishootme: make there a new Wikidata item, then go to Wikidata, search for the new item (might take one or two minutes), which has now the geocoordinates of the place you clicked on, and then add supplementing data. --JopkeB (talk) 12:53, 11 February 2023 (UTC)[reply]
    Wikishootme is fine, but even if I have selected Czech as my language, new items have always English label. And unfortunatelly there is WMF map only. JAn Dudík (talk) 21:52, 13 February 2023 (UTC)[reply]
  • Albeit I would also like this feature, I believe you understand shortcomings and side-effects this can bring. E.g. users changing P625 values (moving features) because they appear slightly off on the map, while the original value was more precise than the map.

Voting

A better way to show differences on Wikidata

  • Problem: When I review changes on Wikidata, all changes appear as exactly the same. In addition, rank ends up on its own line "between" all other edits, which quickly becomes misleading because it looks like many more lines have been changed than it actually has.
  • Proposed solution: I suggest that lines without change with rank do not appear in differences on Wikidata and that changes to references and determinations are somewhat more clearly marked as related to their main statement.
  • Who would benefit: Anyone who patrols and reviews edits on Wikidata.
  • More comments: Would welcome suggestions and constructive criticism on how this could be done.
  • Phabricator tickets:
  • Proposer: Sabelöga (talk) 00:34, 5 February 2023 (UTC)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Wikidata&oldid=25728176"