Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Edit

Vector 2022 will be the default skin

[edit]
A two-minute video about Vector 2022
Something like this, but for Wikidata :D

Hello. We are the Wikimedia Foundation Web team. We are here to announce that the Vector 2022 skin will become the default desktop skin here on 17 March. We will gladly answer your questions, concerns, or additional thoughts! We will also help you adjust things which Vector 2022 may not be compatible with. Check out our FAQ – you will find many useful answers there.

If you are using Vector legacy skin, you may find yourself receiving the Vector 2022 skin. You may select Vector legacy as your global preference to avoid seeing the change. Logged-in users can at any time switch to any other available skins, or stay with Vector 2022 and enjoy choosing between its light and dark mode. Users of other skins will not see any changes.

Why are we changing the skin now

For technical reasons (listed below), we need to deploy the skin soon. After deployment, we will continue discussing issues and questions about the interface, and we'll be ready to work with you on various issues like gadget compatibility.

More details on why we need to deploy the skin now

  • Due to releases of new features only available in the Vector 2022 skin, our technical ability to support both skins as the default is coming to an end. Keeping more than one skin as the default across different wikis indefinitely is impossible. This is about the architecture of our skins. As the Foundation or the movement in general, we don't have the capability to develop and maintain software working with different skins as default. This means that the longer we keep multiple skins as the default, the higher the likelihood of bugs, regressions, and other things breaking that we do not have the resources to support or fix.  
  • Vector 2022 has been the default on almost all wikis for more than a year. In this time, the skin was proven to provide improvements to readers while also evolving. After we built and deployed on most wikis, we added new features, such as the Appearance menu with the dark mode functionality. We will keep working on this skin, and deployment doesn't mean that existing issues will not be addressed. For example, as part of our work on the Accessibility for Reading project, we built out dark mode, changed the width of the main page back to full (T357706), and solved issues of wide tables overlapping the right-column menus (T330527).
  • Vector legacy's code is not compatible with some of the existing, coming, or future software. Keeping this skin as the default would exclude most users from these improvements. Important examples of features not supported by Vector legacy are: the enriched table of contents on talk pages, dark mode, and also temporary account holder experience which, due to legal reasons, we will have to enable. In other words, the only skin supporting features for temporary account holders (like banners informing "hey, you're using a temp account") is Vector 2022.

How to request changes to the skin

We are guessing that some of you may want to see some changes to the skin. We are still improving Vector 2022 and the overall reading experience. If you have a feature request or a bug report, we encourage you to comment here or open a ticket in Phabricator. We will decide on the priority of these requests alongside our regular processes after deployment. Some fixes may be done via gadgets or user scripts, too.

About the skin

Global preferences

We encourage you to try out Vector 2022 by going to the Appearance tab in your preferences and selecting it from the list of skins. Getting used to it may take a few days, and that's the standard for interface changes.

Details about the skin

Vector 2022 is the modernized version of the currently default skin Vector legacy. It is the default on almost all Wikimedia wikis (there are about 10 left now). Most of the active editors use it and do not opt out of the skin at statistically noticeable rates despite easy access to the opt-out link. (Check the source here.)

[Our 2022 answer to why is a change necessary] When the current default skin was created, it reflected the needs of the readers and editors as these were in 2010. Since then, new users have begun using the Internet and Wikimedia projects in different ways. Although there were changes to features the skin supported, the structure, navigation, visual layout, and overall readability of the skin did not change. The old Vector does not meet the current users' needs.

[Objective] The objective for the Vector 2022 skin is to make the interface more welcoming and comfortable for readers and useful for advanced users. It introduces a series of changes that aim to improve problems new and existing readers and editors were having with the old skin. It draws inspiration from previous user requests, the Community Wishlist Surveys, and gadgets and scripts. The work helped our code follow the standards and improve all other skins. We reduced PHP code in the other available skins by 75%. The project has also focused on making it easier to support gadgets and use APIs.

[Changes in a nutshell] The skin introduces changes to the navigation and layout of the site. It adds persistent elements such as a sticky header and table of contents to make frequently-used actions easier to access. It also makes some changes to the overall styling of the page. The analysis of the data collected concluded that these changes improve readability and usability, and save time currently spent in scrolling, searching, and navigating – all of which can be interpreted to create an easier reading experience. The new skin does not remove any functionality currently available on the old Vector skin. On wikis with this skin as the default, there are no negative effects to page views, account creation, or edit rates. On our project pages you will find findings and results in a nutshell.

A summary of findings and results

  • On average, 87% of logged-in users on our early adopter wikis continue to use the new skin once they try it.
  • The sticky header makes it easier to find tools that editors use often. It decreases scrolling to the top of the page by 16%.
  • The new table of contents makes it easier to navigate to different sections. Readers and editors jumped to different sections of the page 50% more than with the old table of contents.
  • The new search bar is easier to find and makes it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the wikis we tested on.
  • The skin does not negatively affect page views, edit rates, or account creation. In fact, there is observational evidence of increases in page views and account creation across partner communities.

How can editors change and customize this skin?

  • We make it possible to configure and personalize our changes. We are happy to work with volunteers with technical skills who would like to create new gadgets and user scripts. So far, many gadgets and user scripts have been built by volunteer developers. These aspects include making the background gray, turning off sticky elements, bringing back the old table of contents, and more. We encourage you to check out our repository for a list of currently available customizations and changes, or to add your own.
  • In Vector 2022, logged-in and logged-out users can change the font size and color scheme based on their individual needs. Dark mode is now available for logged-in users of Vector 2022, and we would like to make it available to logged-out users as soon as most pages are dark-mode friendly.

How will we go through the change

  • Wiki page: we would like to kindly suggest creating a page similar to English Wikipedia's w:WP:V22. It may explain the basics like how to opt-out or customize the skin.
  • CentralNotice banner for logged-in users: before and shortly after deployment, we will display a banner announcing the change. It will be linking to Wikidata:Vector 2022 if you decide to create such a page. Otherwise, it will be linking to this announcement. This should limit the confusion and the number of repetitive questions about the change.

If you think there are any significant technical issues, let us know – perhaps we've missed something. We're looking forward to your comments before and reactions after deployment. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 22:14, 27 February 2025 (UTC) Unarchiving it to keep it a few days after deployment SGrabarczuk (WMF) (talk) 22:14, 20 March 2025 (UTC)[reply]

Tracked in Phabricator
Task T316797
About the page width and sitelinks going to the bottom in the Item, Property, and Lexeme namespaces - we've read comments about this issue, both here on Wikidata and on platforms like Discord, and it will be solved. There is an idea for a quick fix, and there may also be a different solution WMDE would work on. SGrabarczuk (WMF) (talk) 23:45, 27 February 2025 (UTC)[reply]
I have been using Vector 2022 for around a year now, and I haven't faced much issues other than the aforementioned page width issue, and the warning triangle icon of RequestDeletion gadget showing up in an awkward location on items which have an active RFD. Samoasambia ✎ 16:16, 11 March 2025 (UTC)[reply]

Hide

[edit]

Is there a way to hide the languaje label "default for all languages"? Thank you --Fantastoria (talk) 13:31, 1 March 2025 (UTC)[reply]

.wikibase-entitytermsforlanguageview-mul { display: none; } GZWDer (talk) 11:32, 3 March 2025 (UTC)[reply]
Sorry @GZWDer:, but I don't understand what you mean. --Fantastoria (talk) 12:34, 9 March 2025 (UTC)[reply]
Add it to Special:MyPage/common.css. GZWDer (talk) 12:57, 9 March 2025 (UTC)[reply]
Ok, Thanks. --Fantastoria (talk) 13:09, 9 March 2025 (UTC)[reply]

Location names that have changed

[edit]

Cor van Gogh, the youngest brother of the famous painter Vincent van Gogh, died in Brandfort.[1] Brandfort is a town name that has been changed to Winnie Mandela in 2021. The Q number for Brandfort (now Winnie Mandela) is Q2805770. When I search for Cor van Gogh, the result I get shows that he died in Winnie Mandela. Is this a Wikidata problem. If so, how can this be rectified? Derek J Moore (talk) 09:57, 4 March 2025 (UTC)[reply]

I'm not seeing this - maybe you should post a screenshot if it's still an issue? Brandfort (Q2805770) is labeled "Brandfort" in English, and has been for years. ArthurPSmith (talk) 21:58, 5 March 2025 (UTC)[reply]
Hello Arthur. Thanks for the reply. Have done a few Google search queries in the past few days using the phrase "Cornelis van Gogh" and I always get the same result. Here's screenshot https://weblearning.co.za/blog/wp-content/uploads/2025/03/Brandfort-1024x375.png I'm also writing a blog post (as yet unpublished) about this odd situation. I was going to wish you a happy friday. But on second thoughts stay safe might be a more appropriate greeting Derek J Moore (talk) 06:34, 7 March 2025 (UTC)[reply]

References

  1. ↑ https://journals.ufs.ac.za/index.php/jch/article/view/4085

"Also known as"

[edit]

Hello, how do I access the data stored in "Also known as" in a Qid with Module:Wikidata ? 

{{# i n v o k e: Wikidata| getLabel |entity= Qid |lang= mul }}

will get the name - default for all languages 

{{# i n v o k e: Wikidata| getDescription |entity= Qid |lang= fr }}

will get the desc in French

What 

{{# i n v o k e: Wikidata| ?function? |entity= Qid }}

will return "Also known as" list ?

It doesn't seem to be a property, as neither label nor description seem to be properties.

-- 65.92.246.77 22:30, 6 March 2025 (UTC)[reply]

You will be much better off using the Wikidata template or the corresponding Wd module. Plenty of examples on its page, and several wikis have a copy of it, if not ask your local administrator to import it. Infrastruktur (talk) 11:24, 10 March 2025 (UTC)[reply]

Merge for a song?

[edit]

Hi, can someone help me figure out of if these results are all the same? If so, how do I merge them? Myrealnamm-alt (talk) 14:29, 7 March 2025 (UTC)[reply]

Also, there is now w:en:Ça sent si bon la France, which can be connected with one of those items. Myrealnamm-alt (talk) 14:30, 7 March 2025 (UTC)[reply]
A musical work (the song) can have many recordings -- which can be included in musical releases (singles, albums, etc) as tracks.
These should remain distinct items as they each have their own distinct identifiers (ISWC, ISRC, etc) and properties.
You can learn more about the music ontology in the Wikidata:WikiProject Music project. Iamcarbon (talk) 19:06, 7 March 2025 (UTC)[reply]
@Iamcarbon Thanks for the reply. So which should w:en:Ça sent si bon la France go into? The article covers both the song as a single and both tracks. Should it go with Ça sent si bon la France (Q46541479) because that's where I translated the article from?
Also, I strongly believe these two following are the exact same/duplicate:
Could you help me double check these two only? Thanks. Myrealnamm-alt (talk) 19:13, 7 March 2025 (UTC)[reply]
I would recommend associating the Wikipedia page with the song / musical composition, as it's the item shared in common with everything it describes.
Although the last two items appear nearly identical, there is a subtle distinction: the "Single" refers to the release itself, whereas the second item represents the 78 RPM, 10-inch shellac edition of that release. Iamcarbon (talk) 19:58, 7 March 2025 (UTC)[reply]
Thank you for helping me distinguish those items, really appreciated! Myrealnamm (talk) 21:32, 8 March 2025 (UTC)[reply]

Francine M. Benes

[edit]

How should the Emeritus status of Francine M. Benes (Q119495999) be added to the item? Ideally, this would also then be reflected in the corresponding infobox/Wikidata of the w:Francine M. Benes article. -- Cl3phact0 (talk) 18:50, 7 March 2025 (UTC)[reply]

@Cl3phact0: professors are a bit of a mess at the moment. This is because the concept looks the same in most countries, but turns out to be slightly different.
Take for example Andrew S. Tanenbaum (Q92621): American-Dutch computer scientist (no so random example, I had him as a professor). He was nl:Hoogleraar (full professor under Dutch law) and is now a nl:Emeritus hoogleraar (retired full professor under Dutch law). Maybe we need to create per country subclasses to sort it out? Automated imports made the data quite the puzzle to work with. Multichill (talk) 17:01, 10 March 2025 (UTC)[reply]
Thank you for this interesting (and non-random) example. Being neither a data scientist nor particularly expert about this corner of the wikiverse, I don't know that I have too much to add beyond an opinion, and the sense that it may add unwanted complexity to try and capture both administrative legal employment status together with what seems largely a honorific title indicating the retired status of an esteemed academic (notwithstanding differences from country to country). My focus in this case is trying to eke out the best possible results using w:Template:Infobox person/Wikidata (which I find fascinating and woefully underexploited). -- Cl3phact0 (talk) 15:41, 11 March 2025 (UTC)[reply]

Universal Code of Conduct annual review: proposed changes are available for comment

[edit]

Please help translate to your language.

I am writing to you to let you know that proposed changes to the Universal Code of Conduct (UCoC) Enforcement Guidelines and Universal Code of Conduct Coordinating Committee (U4C) Charter are open for review. You can provide feedback on suggested changes through the end of day on Tuesday, 18 March 2025. This is the second step in the annual review process, the final step will be community voting on the proposed changes. Read more information and find relevant links about the process on the UCoC annual review page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) 18:50, 7 March 2025 (UTC)[reply]

Delete or mark as deleted?

[edit]

The following hotel chain does not exist any more: Q16325118: It has been taking over by another hotel chain, FourPoints Flex by Sheraton (Q1439966). The same goes for the invidual hotel Q111409494. What should be done about obsolete Q16325118? Should it be deleted? Or should it somehow (how?) be marked as obsolete?

Troels Arvin (talk) 21:02, 7 March 2025 (UTC)[reply]

We want to record the evolution of companies, so for the chain record the mergers as we do for Vickers (Q13220673), deciding whether the brand still exists within the new organisation. Treat the hotel as a single object with a series of operator (P137) Vicarage (talk) 22:47, 8 March 2025 (UTC)[reply]

Problems to merge with mergeitems tool

[edit]

I've been trying with Special:MergeItems to merge from Q98968175 to Q117422231, but it always shows me the same message: Failed to merge Items, please resolve any conflicts first. / Error: Conflicting descriptions for language en ... Please could someone assist me to solve this?. Fma12 (talk) 22:25, 7 March 2025 (UTC)[reply]

I would recommend to use Merge.js (see Help:Merge#Gadget), which should be easier. D3rT!m (talk) 10:25, 8 March 2025 (UTC)[reply]
In this specific case, just choose the English description you prefer, and simply delete the other one prior to using the tool. --Matěj Suchánek (talk) 14:58, 8 March 2025 (UTC)[reply]

Duplicate entry

[edit]

Q18580797 is a duplicate of Q6412786. Ostensibly one had a typo in the header, and instead of just fixing that (or without knowing it existed), someone created an entirely new entry. Thoughts on what is usually done with entries like this? 04:45, 9 March 2025 (UTC) TheTechnician27 (talk) 04:45, 9 March 2025 (UTC)[reply]

✓ Done I eliminated the typo in Q6412786 and simply merged Q18580797 into it. --Matěj Suchánek (talk) 08:30, 9 March 2025 (UTC)[reply]

Citing a calculated birth date

[edit]

The birth date citation on George James Cottom Broom (Q133200542) is throwing a constraint error.

What's the preferred way to cite a birth date calculated from a cited age at death? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:35, 9 March 2025 (UTC)[reply]

I would go for date of death (P570) qualified with age of subject at event (P3629) and inferred from (P3452) -> age at death (Q50379085) as source for date of birth (P569). See for example Edward "Jock" Stewart (Q124981459). based on heuristic (P887) might also be an option. Multichill (talk) 16:47, 10 March 2025 (UTC)[reply]

zelph: A tool for finding logical contradictions and making inferences in Wikidata

[edit]

Hello Wikidata community,

I'd like to introduce you to zelph, a semantic network system I've developed that can help identify logical contradictions and make deductions within Wikidata's knowledge graph. The project is available at:

  • Website: https://zelph.org (with a tree of 4,580 pages showing deductions and contradictions)


Key features relevant to Wikidata:

  • Contradiction detection: zelph can identify logical inconsistencies in Wikidata's knowledge structure, which could help improve data quality.
  • Inference capabilities: Using a rule-based system, zelph can derive new facts from existing ones (e.g., through transitive relationships).
  • Innovative representation: zelph represents relations as first-class nodes rather than edge labels, perfectly matching Wikidata's approach to properties. Moreover, not only facts but also the inference rules themselves are represented within the semantic network (theoretically allowing rules to generate new rules).
  • Memory efficiency: zelph processes the entire 1.4TB Wikidata JSON into just 9.2GB of memory, requiring only ~80 bytes per Wikidata item.
  • Customizable inference rules: The inference mechanisms aren't hardcoded but defined through a scripting language. The current tree was generated using a script designed to follow Wikidata's usage guidelines.

The system has already successfully processed the complete Wikidata knowledge base multiple times and published results that highlight both potential issues and new connections.

I'm very interested in exploring potential collaboration with the Wikidata community. Any feedback, suggestions, or questions would be greatly appreciated, e.g. regarding the inference rules and their alignment with Wikidata best practices.

Best regards, Stefan Acrion-dev (talk) 14:46, 9 March 2025 (UTC)[reply]

Wikidata 101 MOOC for Beginners (in English) - Starting March 17, 2025!

[edit]

Hi everyone,

We’re excited to announce a rerun of the Wikidata Open Online Course for beginners, starting on March 17, 2025.

About the Course

The Wikidata Open Online Course is designed to simplify learning how to edit Wikidata through a structured online program in English. Originally developed in French by Wikimedia France, the course content has been updated and translated into English.

Whether you're:

  • A beginner taking your first steps,
  • In need of a refresher on Wikidata concepts, or
  • A seasoned trainer looking to level up your skills,

this course is perfect for you. Participants will gain insights into how Wikidata works, its rules, its vibrant community, and how to contribute effectively.

What to Expect

  • Chapter 1: The Wikimedia Movement and the Creation of Wikidata
  • Chapter 2: Understanding Knowledge Graphs and Queries
  • Chapter 3: Discovering Wikidata, Open Data, and the Semantic Web
  • Chapter 4: Contributing to Wikidata, the Community, and Data Quality
  • Chapter 5: Bonus Resources on Scientific Bibliography from Wikidata

How to participate:

  • Head over to Wikidata 101: An Introduction to enroll using your Wikimedia credentials.
  • Don’t hesitate to share this opportunity with your friends and colleagues.

If you have any questions, feel free to leave a note here or write to me directly.

Cheers!

Zita Zage (WMDE) (talk) 10:02, 10 March 2025 (UTC)[reply]

Wikidata weekly summary #670

[edit]
Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2025-03-10. Missed the previous one? See issue #669

Events

Press, articles, blog posts, videos

Tool of the week

  • zelph: A new tool for detecting logical contradictions and making inferences in Wikidata, using a rule-based system to improve data quality and derive new facts. Check it out on GitHub or explore results on the project website.
  • New Tool for Women’s Day: Scheherazade identifies women without articles in your Wikipedia but present in many others, helping editors prioritize creating missing biographies.

Other Noteworthy Stuff

  • Wikimedia Research Fund had launched. You're encourage to submit proposals around Wikidata. The deadline to submit your proposal is April 16, 2025.
  • The 4th iteration of the Wikidata:Open Online Course will begin from March 17 until April 30. Whether you're a beginner taking your first steps, an individual in need of a refresher on Wikidata concepts, or a seasoned trainer looking to level up your skills - this course is right for you.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

Director / governor of the bank of england

[edit]

We have both director of the Bank of England (Q93338235) and Governor of the Bank of England (Q2579905). Are they really something different ? Don't know anything about that position and its history, so … A query of who held that position : https://w.wiki/DNTT one of the item is used more than the other, it seems. author  TomT0m / talk page 15:06, 10 March 2025 (UTC)[reply]

https://www.bankofengland.co.uk/about/people shows there is one governor (and several deputies), and many directors Vicarage (talk) 15:28, 10 March 2025 (UTC)[reply]
OK so it is left to decide whether or not just the governor is organization directed by the office or position (P2389) View with SQID or not. It raises a constraint error because it does not currently have an inverse. If there is several I guess there is a college of presidents (the court of directors) that is actually the head of the organism ? author  TomT0m / talk page 19:54, 10 March 2025 (UTC)[reply]

(Only) a random subset of items about TV series has their episodes set in 'part of'

[edit]

As far as I can see only some television series have their episodes set via has part(s) (P527) (example) but not many others (example). There doesn't seem to be any criteria or rule for when it's set vs when it's not and also I think it should either be reliably consistently always be set or never (in the latter case one could retrieve the episodes via What Links Here or sparql-querying part of the series (P179)).

Also I wonder whether it would be better to have a separate property that complements part of the series for series episodes in particular since has part(s) is used for all kinds of things.

There are also several complications like these:

  • Many series have separate items for only a few episodes but not all
  • Some series (and also podcasts (example)) have very many episodes so this would make the WD item very large/bloated and long to scroll through
    • this is made more a severe issue by that there still doesn't seem to be a keyboard shortcut for adding a statement where the button for it as at an always varying location near the bottom
    • long sections like that also can't be collapsed (by default)
    • nevertheless, as long as the item loads and there are no other technical issues, Wikidata items aren't really meant to be read by humans but just queried and/or used via other UIs such as infoboxes or listeria tables

Now, if episodes are to be set (are they?) and so via has part(s) (P527), then this is inferrable due to part of the series (P179) if that's set on the episodes so I think setting the episodes on the series item is much better done by a bot than time-intensively by editors. The publication date qualifier would also be set via the publication date set on the episode. (And most of that could be imported en masse from IMDb anyway but that's outside the scope of this discussion.)

I think it could be useful to have the episodes linked. It could make various queries easier and more performant (or enable them to be below constraints), enable users to find the Wikidata item they were looking for or related ones, and enables people to better spot which items are still missing.

What do you think about setting episodes on series that way?

This goes to a broader issue but is there a list of briefly summarized regular bot tasks where one can see (here via ctrl+f "series") whether the maintenance/data-populating task one has in mind is already (and still) being implemented?
Prototyperspective (talk) 17:48, 10 March 2025 (UTC)[reply]

part of the series (P179) is much preferable to has part(s) (P527). As to whether an episode of a series is notable, that's up to the superfans involved. Vicarage (talk) 17:59, 10 March 2025 (UTC)[reply]
As to whether an episode of a series is notable I didn't ask that and the part Many series have separate items for only a few episodes but not all is only about it in regards to the subject of linking them all in the has parts i.e. people seeing/querying these may think/draw from that these episodes are all the episodes of the series when they're not and they're not even consistently all episodes that have Wikidata items.
part of the series (P179) is much preferable to has part(s) (P527) Okay so are you saying it should only be set via part of the series? If so I think it should be applied widely and not sometimes that way, sometimes this way, sometimes both ways and that there should be a constraint violation if an TV series episode is set as value into has parts since most users don't know this. Prototyperspective (talk) 23:46, 10 March 2025 (UTC)[reply]

Any way to query Wikipedia infobox templates to sync data with Wikidata?

[edit]
Example: de:Hatu-Hou (Ort))
Example: de:Nächste Ausfahrt Glück – Katharinas Entscheidung)

So for example, I set the video for the full episode on Mr. Bean Rides Again (Q6928419) and there also is a Wikipedia article about this series episode, en:Mr. Bean Rides Again, with an infobox (this) at its top but it's not having the video in it (as en:Goodnight Mr. Bean has). It may also have several other parameters not set where that data is in Wikidata and likewise there could be data in the infobox template not yet in Wikidata but one could just focus on media for now.

This makes me wonder: is it possible to query Wikipedia articles' infobox templates so that one can see which articles with an infobox have some of the infobox parameters that are mapped to Wikidata properties not set for which the Wikidata item has a value set (e.g. a photo)?

Infoboxes on Commons pull all their data in all infoboxes from Wikidata. It's not like that on Wikipedias.

For media, I think the easier way would be what I suggested at Suggest media set in Wikidata items for their Wikipedia articles. This is especially the case if the item doesn't just have an article in one language Wikipedia article but in many language versions. Updating just one item would take very loong and would be difficult and there's thousands of such cases where some good-quality media is set on the Wikidata item but none is in the article. Nevertheless, that's not possible now and even if it was this could still be useful especially since infoboxes have all sorts of data, not just media. (Note that it's not just about setting new data but also about e.g. spotting inconsistencies,errors,vandalism.) Since most data in specified parameters is set in infoboxes in Wikipedia in structured format and Wikidata is meant to be the place for such structured data I thought maybe sth like it is actually possible somehow since that would make a contribution to either more beneficial. Prototyperspective (talk) 00:12, 11 March 2025 (UTC)[reply]

@Prototyperspective You can try https://pltools.toolforge.org/harvesttemplates/ for Wikipedia-to-Wikidata sync but you should be very careful about transferring data this way and pay attention to correct modelling. Moreover such transferred data would not be referenced. For the other direction, you'll probably have to do some sort of monitoring via categories etc. Vojtěch Dostál (talk) 14:59, 11 March 2025 (UTC)[reply]
Great, that's interesting, thanks! So if this direction is already implemented, that could maybe be used for the other direction.
Something I should add regarding using this method to set media in Wikipedia articles, the method described here is probably not the best way to set these as they may sometimes be better placed somewhere in the article and it would only scan the infobox but not whether/which media is set in the article. On the other hand, it also makes sense to set some representative image in the infobox (for some cases that may rather mean moving a media file somewhere in the article into the infobox). It would also have to check whether the media file is used elsewhere in the article. However, if not there could still be a very similar one or the extra file be too much/redundant.
Then regarding other data, maybe it's relatively uncommon that Wikidata items contain some data that the Wikipedia articles don't contain but since there is such a large number there's probably lots of data that could be added to there and it would be a major use-case of Wikidata. Not many Wikipedians go on Wikidata to see whether it has some data or some new data since they last checked that they could add into the infobox. I think many Wikipedias have infoboxes that use data from Wikidata. Maybe somebody clarify all this a bit. For example, why not have the infobox display data from Wikidata (maybe imported by a bot from there) if nothing is entered for parameters? I think something is not unlikely already being done but I don't know what there is, maybe it's in some Wikipedia tools page. Prototyperspective (talk) 01:39, 12 March 2025 (UTC)[reply]
Hello, on the one hand there are PetScan/QuickStatements/HarvestTemplates etc. to enhance wikidata items, for example:
On the other hand, there ist the
(also see screenshots), where infos can be exported by double clicking on the red (=missing) information in the infobox / wikidata item. M2k~dewiki (talk) 20:40, 12 March 2025 (UTC)[reply]

Wikidata item for Wikimedia project category for item with its own Wikidata item

[edit]

Q24044101 is for "Category:Paraselenis", and has the Wikimedia Commons category linked to it, thus forbidding it from being linked to Q2443412, which is "Paraselenis". Doesn't this defeat the purpose of Wikidata? Is it standard for Wikimedia Commons categories to be linked to meta-entries like this rather than to the entry that corresponds to the actual subject matter? Zanahary (talk) 05:51, 11 March 2025 (UTC)[reply]

@Zanahary: Yes, this is perfectly normal and is the intended behaviour. Paraselenis (Q2443412) is linked through Category:Paraselenis (Q24044101) to the Commons category. That's why the data from Paraselenis (Q2443412) shows up correctly while looking at the Commons category. — Huntster (t @ c) 14:43, 11 March 2025 (UTC)[reply]
Is there a way to see that the Commons category exists from the Paraselenis Wikidata item? Zanahary (talk) 16:14, 11 March 2025 (UTC)[reply]
@Zanahary: The normal practice is to add Commons category (P373) to both the subject item and the category item, but the interwiki link (under "Multilingual sites") only goes to the category item. That said, it's only necessary to add Commons category (P373) to the category item when such an item exists. — Huntster (t @ c) 20:59, 11 March 2025 (UTC)[reply]
Yes: Q2443412#P373. Jonathan Groß (talk) 16:16, 11 March 2025 (UTC)[reply]

Documenting repeated deletions: Sakurako Miki and Sakiko Miki

[edit]

At commons:Special:Diff/1007617797, Nakonana told me that the Wikidata items for Sakurako Miki (currently Sakurako Miki (Q125694445): Japanese girl) and Sakiko Miki (currently Sakiko Miki (Q125693481): Japanese girl) have been deleted and recreated multiple times.

The current items cited in the previous paragraph were created on and have no logs. Searching Wikidata (excluding the File namespace) or the Requests for deletion archive does not give any other results. This situation would not arise on any other project. It arises on Wikidata because every item is identified by a meaningless string of digits prefixed by ‘Q’, that apparently cannot be assigned meaning again once the item has been deleted.

There is plenty of discussion about Sakurako and Sakiko on Commons, which is easy to find. Surely there is discussion about Sakurako and Sakiko on Wikidata too, but I have no idea how to find it. Surely there is also discussion about making the Requests for deletion archive more usable, but I cannot find that either. Brianjd (talk) 02:50, 12 March 2025 (UTC)[reply]

As another example, I found Wikidata:Requests for deletions/Archive/2025/03/11#Q72384834, where one user said the item was non-notable, another user said it was notable, and the item was simply deleted without further discussion. We may never know whether it really was notable.
I don’t intend to look further. Brianjd (talk) 04:13, 12 March 2025 (UTC)[reply]
I don't know whether it will be of any help for you, but the way I noticed that there have been Wikidata items on the two girls in the past was by spotting Pi bot's edits in the history of "Category:Sakurako Miki" and her sister. Pi bot was adding the then current qIDs and listing them in the edit summary. What you'll find this way for Sakurako is at first Q113989811: no description, which was then removed[1]. Then there was some back and forth[2][3] which ended with the statement that the Wikidata item has been deleted[4]. Some time later you see Pi bot adding a new Wikidata item to the category: Q120549006: no description. That one was later deleted: [5]. I don't know where the deletion discussions happened, though, or whether there were any discussions at all. Nakonana (talk) 21:40, 12 March 2025 (UTC)[reply]
It looks like identifying the qIDs is the key to find the discussions:
That's what I could find when searching for the first qID listed for Sakurako. Nakonana (talk) 21:50, 12 March 2025 (UTC)[reply]

FYI: Wikisource and Wikidata together: lessons from the Wikisource Conference

[edit]

https://diff.wikimedia.org/2025/03/12/wikisource-and-wikidata-together-lessons-from-the-wikisource-conference/ —Justin (koavf)❤T☮C☺M☯ 07:49, 12 March 2025 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2323887563"