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.
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
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)[reply]
(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)[reply]
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)[reply]
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.
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.
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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.
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)[reply]
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
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 edits15:19, 8 February 2022 (UTC)[reply]
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)[reply]
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 havebeenstalled 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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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
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
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)[reply]
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)[reply]
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)[reply]
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:
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)[reply]
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
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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
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. — putnik09:19, 14 January 2022 (UTC)[reply]
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.
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.
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)[reply]
@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. —Ivi10400:39, 15 January 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)
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)[reply]
@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)[reply]
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.
Support This is a common issue that should be resolved as expeditiously as possible to help guide Wikidata's growth. {{u|Sdkb}}talk03:49, 29 January 2022 (UTC)[reply]
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
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)[reply]
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.
@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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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"
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
Problem: Wikidata contains lexical items that can be displayed as translation equivalents for a word sense: (1) lexeme senses in two languages that are linked to the same item with property P5137 'item for this sense', (2) lexeme senses of one of the language that are linked to some item with property P5137, and that item having a label in the other language, (3) item labels, if an item has labels in the desired languages, (4) repeating the same with synonyms (P5973), (5) P5972 sense translation links. It would be helpful to have a tool like Hauki (the proposed tool could well be based on that), which lets select desired source language and target language(s), and displays all found equivalents, combining the above queries, and that lists the results, referencing the source.
Proposed solution: A tool e.g. based on Hauki that displays translation equivalents from the different sources described. Two kinds of use cases:
Translation equivalent lookup. A view like in a dictionary entry would be helpful, with part-of-speech sections and indented sense blocks, and some visual markup of different equivalent types (P5137-linked sense lexicalisations, P5973 synonyms, any P9970 'predicate for' relation, labels and aliases of the pivot item), and, if available, sense glosses, examples, etc.
P5137/P5972/P5973-editing task. Propose item through reconciling a sense lexicalisation against item labels, and also give linked multilingual lexicalisations and glosses as support for the manual validation decision of the user. Ideal would be one-clik validation or rejection of the proposed P5137/P5972/P5973-links. This would shortcut going through OpenRefine, and additionally offers multilingual info, already linked to the proposed item. That is very useful for multilingual users.
Who would benefit:
Users who want to find translation equivalents
Lexicographers
Wikidata contributors, or the task of adding missing P5137/P5972/P5973 statements
More comments: Lexicographical data on Wikidata is becoming more and more powerful; P5137/P5972/P5973 coverage is a key issue for further improvement towards a use for a human-readable multilingual dictionary.
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)
Oppose KingAntenor (talk) 07:05, 2 February 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)
17:02, 29 January 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)