Community Wishlist Survey 2022/Wikidata

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



Do not follow sitelink redirects when redirect badge is used

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

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

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

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

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

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

Discussion

Some history of this topic:
I think we need this final step to start linking redirects properly. — putnik 22:54, 10 January 2022 (UTC)[reply]
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]
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)[reply]
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)[reply]

Voting

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

Discussion

Voting

Dedicated section for everything meta on item pages

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

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

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

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

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

Voting

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

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

(original:

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

)

Discussion

Voting

Search box autocomplete (suggestion) should work for all namespace

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

Discussion

Voting

A tool to delete all references from an item

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

Discussion

Voting

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

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)[reply]
  • 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]
  • Would be very useful at least in ru-wiki Ghuron (talk) 17:47, 19 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]

Voting

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

Discussion

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

Voting

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

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

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

Voting

Creation protection for items

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

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

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

Voting

Feature to change the order of the references and qualifiers

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

Discussion

Voting

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

Discussion

Voting

Rework Lexemes to be more intuitive

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

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)[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. —Ivi104 00:39, 15 January 2022 (UTC)[reply]

Voting

Property proposal helper script

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

Discussion

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

Voting

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

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

Voting

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

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

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

Voting

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

Discussion

Voting