Jump to content

Wikidata:Project chat

Shortcuts: WD:PC, WD:CHAT, WD:?
From Wikidata

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]
The new skin seems… completely unusable (like… literally, and I mean that literally!) on mobile? Sorry, maybe I’m doing something wrong or it’s some temporary glitch or something, because… I don’t believe I am the only one to try that, but I went in a private window (to remove all dependencies on my user settings and style) to e.g. [1] (and other random items) and… well, in all browsers I tried that (Firefox on desktop, Edge on desktop, Firefox on Android, Chrome on Android, Firefox Focus on Android), it was utterly broken, with all statements shown in a tiny vertical strip stuck between the termbox and the right sidebar with the rest of the page empty‽ (explained by Samoasambia below: the mobile skin will not be changed)
And… what I came to report originally was that the desktop view of the new skin is unusable for me on narrow screens, esp. on mobile when sidebar menus are shown (just a bit less terrible when only one is visible): the statement boxes split is bonkers: OK, the darker part for the property is OK-ish, but in the lighter value part, the edit section has a huge fixed width, with the (most important) value section receiving what’s left. Which, when on a narrow screen with both sidebars visible, is usually just a single-letter column; when only a single sidebar is shown, the value has something like five-letter lines, so not great as well. But bad luck for qualifier values and references either way, vertical writing you go.
--Mormegil (talk) 08:48, 14 March 2025 (UTC)[reply]
Also not a fan of the new design. And also even less of a fan of editing being impossible on mobile outside of labels and aliases.StarTrekker (talk) 11:35, 14 March 2025 (UTC)[reply]
The mobile website uses Minerva Neue skin, not Vector 2010 nor Vector 2022 which are meant for the desktop site. Forcing a different skin for mobile website with an URL parameter will obviously give a wrong result. Samoasambia ✎ 12:10, 14 March 2025 (UTC)[reply]
Thanks for the explanation, so the mobile skin won’t be changed, so that problem is moot. Anyway, the desktop view is quite unusable on narrow screens/mobile devices. The stylesheet tries to solve the problem, but apparently the thresholds for hiding the sidebars are too large. See a screenshot. --Mormegil (talk) 16:36, 14 March 2025 (UTC)[reply]
The Web team could’ve spent some of their time fixing Wikidata-specific bugs with Vector 2022 before rolling it out, but apparently that’s entirely unnecessary. Even fixing the two-column view of Wikidata pages is apparently too much work. What a shame. stjn[ru] 20:52, 17 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]

(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]
It's not really necessary to record single episodes on the TV series' item, the relevant information is already stored in the episode items. Listing the episodes on season or series items (or season items on the show's item) is usually done more as a helpful way to show users who maintain these kind of items that the episode items exist. Personally, I would maybe use has part(s) (P527) to list episodes on items of miniseries (even though miniseries should also get season items), or for special episodes that aired outside of a normal season structure. But never for episodes of a normal show. Querying the statements on the episode items is the intended way of getting that kind of information. --2A02:810B:581:C300:A8BD:9AFE:1E2F:8237 17:43, 17 March 2025 (UTC)[reply]
Assuming is usually done more as a helpful way to show users who maintain these kind of items is the case as you said, then isn't that useful so editors can for example see which episodes are missing? On the other hand, I think episodes like series should usually be imported from some series database instead of being created manually and therefore this wouldn't be that useful.
Maybe series items should get some button 'View episodes' that runs the query and shows the episodes in an embedded frame within the item with a click? Prototyperspective (talk) 18:40, 17 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]
Interesting, thanks!
However, that also seems to be only about Wikipedia->Wikidata export but not the other way around. Since you wrote on the other hand I thought the screenshots were showing how to import data from Wikidata into the Wikipedia infobox where one would click the red template parameter cell to add the suggested value until the edit is finished and then published by the user (I think better than that would be a way to view articles in quick succession where the data from Wikidata is suggested to be edited or that a bot does this automatically).
Is there a info page on Wikidata somewhere about everything relating to Wikipedia templates? It's how Wikipedia records structured data alongside article categories so I think both of these should be used to write Wikidata and be written using Wikidata data (both should be more or less in sync). Prototyperspective (talk) 19:38, 14 March 2025 (UTC)[reply]
For the German language wikipedia there is
M2k~dewiki (talk) 19:44, 14 March 2025 (UTC)[reply]
Okay thanks. So it looks like there is not yet an overview page in Wikidata. For other editors coming to this thread: what is still missing is info on how to sync Wikidata->Wikipedia (or a way to do so if it's not possible). For example to query a few hundred items and then for all the attached Wikipedia articles across languages that have a certain infobox, add certain data from Wikidata (such as the name of the film director or the infobox image is none is set). Prototyperspective (talk) 19:53, 14 March 2025 (UTC)[reply]
Also see for example:
M2k~dewiki (talk) 20:11, 14 March 2025 (UTC)[reply]
Thanks again, if nobody else does so, I'll likely compile some meta page about data in templates like infoboxes. Nevertheless, the pages you linked are if I understood correctly only about templates that load data from Wikidata but those are not about writing normal/any templates using data in Wikidata. This is what I'm most interested when it comes to templates.
Furthermore, I also could not find a page that lists specifications of what can be imported from templates like the IMDb link via the IMDb title template. Seems like people just guess what other users are or aren't importing and then run some import once or so but never again thereafter. If a user regularly runs imports from a hundred different templates and then stops editing, nobody would continue these imports. Prototyperspective (talk) 17:59, 17 March 2025 (UTC)[reply]
Wikidata:How to use data on Wikimedia projects and Wikidata:Infobox Tutorial could be of interest, too, and another entry into the rabbit hole. --Matěj Suchánek (talk) 18:46, 17 March 2025 (UTC)[reply]
For example, why not have the infobox display data from Wikidata (maybe imported by a bot from there) if nothing is entered for parameters? Some wikis do this, some do not. The reasons why not include lack of know-how, quality concerns or simply fear of having to learn to edit in another way. English Wikipedia has already held several RfC's on this, these should give you the idea. --Matěj Suchánek (talk) 17:10, 14 March 2025 (UTC)[reply]
There are Wikipedia languages that will extensively use Wikidata Infobox in templates to load, but they tend to be the sparser and less developed Wikipedias that rely more on automated article creation and machine translation.
The one exception being Wikimedia Commons that uses the commons:Template:Wikidata Infobox on a huge number of categories. That template does a huge number of things like add interwiki links. However it is also very complicated and a bunch of modules (programmed in Lua I think). So complicated and heavily used that editing of the template and modules are limited to a small number of users.
On English Wikipedia I think the most commonly used template box that uses Wikidata is en:Template:Authority control. William Graham (talk) 20:29, 14 March 2025 (UTC)[reply]
It's possible for Wikipedia templates to import data from Wikidata. The Commons template do that. For other Wiki's, each Wiki has their own policies. Given that the rules (and also module) in every Wiki are a bit different it's unclear to me what a Wikidata page about it would help. ChristianKl ❪✉❫ 18:46, 15 March 2025 (UTC)[reply]

Comment: Another good resource for anyone interested in the use of Wikidata in enwiki infoboxes can be found here: w:Category:Articles with infoboxes completely from Wikidata. Some of the articles result in better outcomes than others, and there are examples using many different types of Wikidata generated infoboxes. -- Cl3phact0 (talk) 10:55, 17 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[2]. Then there was some back and forth[3][4] which ended with the statement that the Wikidata item has been deleted[5]. Some time later you see Pi bot adding a new Wikidata item to the category: Q120549006: no description. That one was later deleted: [6]. 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]
I created a tool to help with this problem. Currently it is only accessible by admins and rollbackers.
Sakurako Miki Q113989811 (Eien20), Q120549006 (2404:0:8516:9F92:5C42:2DFA:3926:ABC0). CC deleting admins @Fralambert, Ymblanter
Sakiko Miki: Q113989871 (Eien20), Q120549314 (2404:0:8516:9F92:5C42:2DFA:3926:ABC0). CC deleting admins @Fralambert, Ymblanter
Bovlb (talk) 01:20, 14 March 2025 (UTC)[reply]
This is helpful. I don’t have time to look at details now. What I see so far is Wikidata ignoring some important facts:
  1. The Commons help desk is not a deletion forum.
  2. The categories’ actual deletion requests on Commons were all closed as ‘kept’.
  3. Data on Wikidata is displayed in a category infobox as if it was part of the category, so deleting it from Wikidata directly harms Commons. Wikidata should have an equivalent of c:COM:INUSE to mitigate that harm.
Brianjd (talk) 02:58, 14 March 2025 (UTC)[reply]
The wd-deleted results match the Commons Pi bot edits, giving a total of three Wikidata items (two deleted) for each subject.
On , the first Wikidata item for Sakurako was deleted as not notable per Wikidata:Requests for deletions/Archive/2022/11/10#Q113989811. At the same time, the first Wikidata item for Sakiko was deleted as not notable without discussion. The discussion incorrectly claimed that the category was out of scope per c:Commons:Help desk/Archive/2022/10#Category:Sakurako_Miki; that is not a deletion forum. The first actual deletion request (c:Commons:Deletion requests/Files in Category:Sakurako Miki) was closed as ‘kept’ withdrawn after less than 9 hours (and there were no substantial comments between then and the request being closed as ‘kept’).
On , the second Wikidata item for each of Sakurako and Sakiko was deleted as a recreation of a deleted item per discussion (the second and third last discussions at Wikidata:Requests for deletions/Archive/2023/07/17). Q120549314 had another deletion rationale: a reference to WD:LP. Both discussions had this comment: The uploader added all her picture since her birth on Commons. Probably have to warn them a deleted them all. This comment did not say what the problem was and ignored the earlier deletion request; it also falsely claimed that all the images were uploaded by the same user (as far as I can remember, they were uploaded by many different users). In a strange coincidence(?), a few hours later, both Commons categories had deletion requests created. Both of those requests were eventually closed as ‘kept’, yet the Wikidata items remained deleted. Brianjd (talk) 11:39, 15 March 2025 (UTC)[reply]
At least four different uploaders. And that’s just for the small subset of images I documented so far. Brianjd (talk) 11:52, 15 March 2025 (UTC)[reply]
Since the subject was minor, We have a WD:Living people policy. Having a category alone on Commons is not part of our WD:N policy alone (It could be if it have notable identifier or fullfil a structural need). Also, that item was recreated many time instead of simply ask the first deleter to undeleted a previous deleted item. Fralambert (talk) 12:21, 15 March 2025 (UTC)[reply]
I may also add that neither of these items have references so they are violating WD:LP. Fralambert (talk) 12:32, 15 March 2025 (UTC)[reply]
Having a category alone on Commons is not part of our WD:N policy alone Correct.
It could be if it have notable identifier It doesn’t.
fullfil a structural need Does it? It contains important information such as the birth date and the relationship between Sakurako and Sakiko, which is displayed in the category infobox and used to help sort the images on Commons. Is that enough?
Also, that item was recreated many time instead of simply ask the first deleter to undeleted a previous deleted item. How could a user even know that that there was a previous deleted item? That’s one of the main points of this discussion.
I may also add that neither of these items have references so they are violating WD:LP. @Nakonana: Can you comment? Brianjd (talk) 13:31, 15 March 2025 (UTC)[reply]
I'd say that the repeated recreation of the items by different people is an indicator that there's no consensus for deleting them.
I also agree that the Wikidata item helps with properly categorizing the images on Commons (e.g. in categories such "Girls by age"). As for the references, the birthdays of the girls are provided by the primary uploader on Flickr (i.e. the father of the girls) who documents the events in the photos and the age of the girls at the time the photos were taken. If I remember correctly, it was either the photos of the girls as babies, shortly after they were born, that contained the information regarding their birth dates, or there were some birthday celebration photos that contained the date of birth. It's possible that I had added the relevant reference files in hidden notes in the main category for each girl before I finally recreated the Wikidata item. So, looking through my edits in the category history might help finding the references. (I can't do that myself right now because I'm on mobile and going places.) As for creating new Wikidata items instead of asking for undeletion of the old ones, I didn't (and still don't) know where to go and how to make an undeletion request on Wikidata, that's why I chose the process that I know how it works. Nakonana (talk) 13:51, 15 March 2025 (UTC)[reply]
Then source the date of the birth with flickr files, because they have actually no source. Some people still aim these pictures for RfD, you know. Fralambert (talk) 14:04, 15 March 2025 (UTC)[reply]
Here are the relevant files with the birth dates:
Nakonana (talk) 14:16, 15 March 2025 (UTC)[reply]
I didn't (and still don't) know where to go and how to make an undeletion request on Wikidata: You might find Wikidata:Guide to requests for undeletion useful on this point. Bovlb (talk) 16:32, 15 March 2025 (UTC)[reply]
Thanks! Merging the deleted items with the new ones is probably not an option, is it? Can admins see whether the deleted items had any information that the current items don't have and that might be worth merging? Nakonana (talk) 17:11, 15 March 2025 (UTC)[reply]
I still want to highlight the original issue here: it is impossible to make sense of deleted items on Wikidata. I just happened to find Yoshihito Miki (Q120548822): Japanese photographer (Yoshihito Miki, Sakurako and Sakiko’s father), which was delinked from Q120549006 and Q120549314 after they were deleted. There is no ‘delinker log’ like there is on Commons. For what it is worth, Yoshihito is also unsourced and possibly non-notable. Brianjd (talk) 14:22, 15 March 2025 (UTC)[reply]
Yes, it's generally impossibly to fully reverse the deletion of an item when the item had incoming links. The links are automatically removed and I'm not aware of any log. In many cases, the existence of incoming links is evidence of notability, so we are cautious in deleting such items. In addition, those incoming links ought to be considered as part of any deletion review.
It would be nice if we could snapshot incoming links when items are deleted. Bovlb (talk) 16:38, 15 March 2025 (UTC)[reply]
Yoshihito Miki has primary sources such as his Facebook account as references. I'd also say it's worth keeping his Wikidata item because there are thousands of professional quality photos by him on Commons, documenting things such as Japanese festivals and customs which is clearly educationally valuable. If I remember correctly, some of his photos are also used on Wikipedia. Nakonana (talk) 17:23, 15 March 2025 (UTC)[reply]
Some properties do have references; I missed that earlier. Regarding notability, unfortunately, we have to work with Wikidata’s notability policy; as I pointed out at c:Template talk:Wikidata Infobox#Infoboxes for categories that are below Wikidata’s threshold of notability, Wikidata’s policy is generally stricter than Commons’ policy. I was hoping that someone more familiar with Wikidata would explain how that policy applies here.

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]

Mass import of bad data - title page value

[edit]

Saiphani02 (talk • contribs • logs) is mass importing bad data. I have explained the problem on their talk page, but they shrugged this off and continue mass importing the bad data. They are importing values of "page displayed" from Wikisource Index pages, which may be a title page, or a frontispiece, or a bound cover, or something else. Looking at the values imported, nearly 99% of them are incorrect so far because they are the first page of the scan, not the title page, which is typically 7 or 9 pages into a scan of a Wikisource copy.

This will require a mass revert to remove all the bad data. --EncycloPetey (talk) 15:28, 13 March 2025 (UTC)[reply]

Examples of the problem:
Thus far, after checking lots of these edits, I have found only a single instance where the claim of title page location was correct. --EncycloPetey (talk) 15:46, 13 March 2025 (UTC)[reply]
Update: Where I have pointed out and removed an error [7]; the user simply adds the incorrect info back onto the data item.
Since the user is refusing to acknowledge the data is bad; is refusing to consider the data is bad; has claimed to have stopped, but in fact has not; and is continuing to not only add bad data, but is restoring bad data that was removed, this user may need to be blocked to protect the project. --EncycloPetey (talk) 16:41, 13 March 2025 (UTC)[reply]
I understand that the value of "Image" might not be as accurate in the Wikisource index page template and have stopped the temporary batch - #temporary_batch_1741877013384 and the batch #244414 immediately as soon as @EncycloPetey brought it to my notice. the batch #244414 added couple more qualifiers after 50 minutes for reasons I'm unaware of. Saiphani02 (talk) 18:04, 13 March 2025 (UTC)[reply]
It took two sets of requests and posting twice here to get the process stopped. But now, knowing that the data was bad, you should voluntarily remove the bad data. --EncycloPetey (talk) 18:39, 13 March 2025 (UTC)[reply]
done. Saiphani02 (talk) 19:09, 13 March 2025 (UTC)[reply]

email address (P968)

[edit]

Which statement to use for email address (P968) at Gmail (Q9334)? maintained by (P126) doesn't fit. Eurohunter (talk) 20:42, 13 March 2025 (UTC)[reply]

Why do we need to add a qualifier to say that when it's obvious from the email address itself? Midleading (talk) 15:28, 16 March 2025 (UTC)[reply]

QLever wikidata index updates / QLever service/instance with current index

[edit]
Tracked in Phabricator
Task T386401

Hello, for some SPARQL-Queries I have been using

when

returns a timeout. In the past, according to the button "Index information" on QLever the wikidata index has been updated almost every weekend (Saturday or Sunday). At the moment, "index information" shows, that the index has been updated on 29th of January 2025. Is there another service which is using the QLever software, but with a more current wikidata index?

Thanks a lot! M2k~dewiki (talk) 22:23, 14 March 2025 (UTC)[reply]

@M2k~dewiki - The file latest-all.ttl.bz2, located under /wikidatawiki/entities/ and referenced when you click the "Index information" button on the QLever website, is still dated January 29, 2025. Attempting to download it results in a 404 error, and its size is just 43 bytes, so i think that might be the issue. Difool (talk) 01:38, 15 March 2025 (UTC)[reply]
Tracked in Phabricator
Task T388954
Thanks a lot! I have opened https://phabricator.wikimedia.org/T388954 now. M2k~dewiki (talk) 01:51, 15 March 2025 (UTC)[reply]

sameAs

[edit]

I've just noticed that schema.org's official definition of sameAs says:

URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Wikidata entry, or official website.

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:12, 15 March 2025 (UTC)[reply]

Merge request

[edit]

Hi all

I just created a Wikipedia article and then created a Wikidata item to go along with it, unfortunately a bot also created an item at the same time, could I ask someone merge them? Also the bot added names to multiple languages which looks like its wrong.

  • Q133283498
  • Q133283476

Thanks

John Cummings (talk) 13:11, 15 March 2025 (UTC)[reply]

Hello, the two items have been merged. Also see Help:Merge. M2k~dewiki (talk) 13:26, 15 March 2025 (UTC)[reply]

Can anyone help me how to fix this constraint error?

[edit]

Q115789820#P275 Trade (talk) 14:47, 15 March 2025 (UTC)[reply]

Licenses can only be granted for copyrighted works, so copyright license (P275) isn't applicable here. ineligible for copyright protection (Q61005058) is not a license, it's an explanation/justification why we/our source thinks the work isn't copyrighted. If the work is indeed public domain (which I'm not entirely sure of after reading the linked sources), ineligible for copyright protection (Q61005058) should be added to the copyright status (P6216) statement as a value of a determination method or standard (P459)qualifier. --2A02:810B:581:C300:A073:896:3280:2EE 23:42, 15 March 2025 (UTC)[reply]
So what value should i replace it with? Trade (talk) 03:31, 16 March 2025 (UTC)[reply]
IMHO, none. If a work wasn't explicitly released under a specific license, copyright license (P275) isn't needed. copyright status (P6216) is enough to record its public domain status. --2A02:810B:581:C300:A8BD:9AFE:1E2F:8237 17:27, 17 March 2025 (UTC)[reply]

polyL

[edit]

I just simplified the English description on polyL (Q7226108), which was overly detailed. The Slovenian description also appears to be very verbose, but I don't speak Slovenian, so I don't know how to simplify it. Any Slovenian speakers here? TTWIDEE (talk) 21:08, 15 March 2025 (UTC)[reply]

Perhaps you can find Slovenian speakers at Wikidata:Project chat/sl. Also ping @TadejM. --Matěj Suchánek (talk) 10:30, 17 March 2025 (UTC)[reply]

Valid Google Play author ID not matching regex

[edit]

The Google Play author ID (P12871) 11fnxrlx72 is marked with a regex error on Thane K. Pratt (Q70784628), even though the identifier resolves correctly. Any way to fix the regex so it doesn't come up with this false flag? BhamBoi (talk) 05:49, 16 March 2025 (UTC)[reply]

✓ Done The value has 10 characters, whereas the constraint allowed only 8. There were even more violations like this, hence I updated the regex. --Matěj Suchánek (talk) 08:28, 16 March 2025 (UTC)[reply]

Adding tempers to alloy data sets

[edit]

I noticed something that needs to be brought up sooner rather than later if you want your datasets to be complete and well organized by engineering and material science standards.

Each alloy needs a subcategory of tempers. Tempers can have a significant influence on yield strength and tensile strength of a material, and NEEDS to be a subcategory before you start to enter those kinds of properties into the data set. (Or maybe something more general, like temper/manufacturing process, as some alloys are cold worked during the manufacturing process and that's technically different from temper.)

For instance, aluminum 6061 O temper has a yield strength of 55-65 MPa. Whereas aluminum 6061 T6 has a yield strength in the region of 276 MPa. This needs to be a habit for people adding alloys to your database.

I actually created a table of properties and tried uploading it to wikipedia some years ago. It seems there was a purge a few years ago taking down tables with "too many" data points. I understand that an encyclopedia should be general information, but rather than deleting it, they could have transferred it to your wikidata sets. Given I'm largely unfamiliar with your processes and practices here, I'm not sure how to convert my tables (that I had copies of because of their utility to myself). I would like to contribute that data, but citing my sources other than in a general sense will be problematic. Would the wikidata community like me to attempt it anyway? This is a smart idea to better organize bigger data sets rather than tables like I was doing on wikipedia, and there is potential for me to add many of the engineering properties tables from my textbooks if I can get some help navigating your system and making sure I add the data to the correct locations. Given I'm an engineer and more used to dealing with tables than databases, I would need some guidance on how you have things organized and where those tables ought to end up if I'm going to be adding useful data in the right place to contribute in any meaningful way (given the fairly strict standards of the wiki community).

This is a wikipedia table I was planning on adding to your database: User:Jlefevre76/isotropicmaterialproperties - Wikipedia Guidance from the wikidata community on how to go about that would be welcome. Jlefevre76 (talk) 16:49, 16 March 2025 (UTC)[reply]

I sort of put together a couple of examples of how we might go about it. Using 6061 as an alloy, for instance, and then use 6061 T-6 and 6061 O-temper as subcategories of the aluminum (or aluminium if you're from the UK) 6061 alloy. I think this might be a good template for how we should organize the different tempers/manufacturing processes as subcategories of each alloy.
FYI, it got a little messy, as spelling and data type makes it difficult to find properties pages like coefficient of thermal expansion and fracture toughness. I recreated both pages which incidentally were not in existence as property with quantity data types. I wish there were a better way of converting the existing pages into property of quantity data types. I made the requests and maybe they will use the existing page's data to create the appropriate, usable property page? Jlefevre76 (talk) 21:14, 16 March 2025 (UTC)[reply]

Confirmation Google Knowledge Graph ID

[edit]

At the moment, confirmation (Q214802) has three Google Knowledge Graph ID (P2671) statements. When I click on the links, the latter two (https://www.google.com/search?kgmid=/g/11dykjs_n and https://www.google.com/search?kgmid=/g/120s1v6n) show me exactly the same Google results page, and for the first link (https://www.google.com/search?kgmid=/g/120x6cwp), the results seem to be the same, too. So I do not know which of these statements actually refers to which item (an item should only have one Google Knowledge Graph ID (P2671) statement, according to the constraint violation).

Could someone who is familiar with Google Knowledge Graph please move at least two of the three statements to other items? In particular, Q133292863 (for confirmation in Protestant churches, confirmation (Q214802) is apparently supposed to be the specialization to Lutheran ones) is lacking any Google Knowledge Graph ID at the moment. --2A02:8108:5091:E900:41F3:3057:9966:B41F 17:53, 16 March 2025 (UTC)[reply]

Bad merges

[edit]

I noticed that a year ago Christian Yakubu has done thousands of author mergers with Wikidata Games many of which were incorrect. I already went through the edits between 14 and 20 February 2024, and found and reverted dozens of bad merges. If you wanna help, please pick a date, comment it below, go through the merges and revert the bad ones. Thanks to ArthurPSmith for already reverting many of them during the last year. Samoasambia ✎ 20:38, 16 March 2025 (UTC)[reply]

@Samoasambia: Thank you for your work. I am not familiar with this specific editor but I've come across many similar cases. People just merging items left and right.StarTrekker (talk) 20:51, 16 March 2025 (UTC)[reply]
According to https://outreachdashboard.wmflabs.org/users/Christian_Yakubu, this user is an instructor for multiple outreach programs that target Wikidata among other projects. Bovlb (talk) 02:06, 17 March 2025 (UTC)[reply]
@Bovlb: has undone several merges, but this is not enough - KrBot resolved the redirects, so the papers now linked to wrong author items. This should also be reverted. GZWDer (talk) 11:02, 17 March 2025 (UTC)[reply]
Thank you very much for the corrections.Please am very sorry for the wrong merges.ArthurPSmith showed me a different way to contribute without merging which I learnt.But I would be happy to be guided on how I can help undo some of these.
Thank You. Christian Yakubu (talk) 14:34, 17 March 2025 (UTC)[reply]
To fix the problem, you need to:
1. Review your merges to find bad merges that have not been fixed. This link might be a good starting point.
2. Undo your changes, or revert both items to a pre-merge state.
3. Review every page on the "What links here" for the merge target, to see if they need to be moved back.
In addition, it would be useful to know how this problem arose, as you are not the only editor to have made bad merges. Is there something missing or wrong in the instructions, the tool's interface, or some training course that leads to this problem? What could be improved? Bovlb (talk) 15:49, 17 March 2025 (UTC)[reply]

Is there any way to sort items by qid in Special:AllPages?

[edit]

I've been wondering about this for a while. 46.10.16.130 16:34, 17 March 2025 (UTC)[reply]

Wikidata weekly summary #671

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

Discussions

Events

  • Upcoming events:
    • Call for Wikimania 2025 Programme reviewers. Apply until Monday 17 March 12:00 UTC
    • Wikidata Affinity Group Update: The fourth session of Starting a Wikidata Project, originally set for March 18, will now be an asynchronous Slack discussion in the #wikidata channel of the LD4 Slack Space. Join us at 9am PT / 16:00 UTC to discuss Reporting Your Outcomes and Results. Join Slack here. Note: April programming will pause as we prepare the next series.

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • Wikibase REST API: We continued the work on adding search to the API (phab:T383126)
  • Search: We are continuing the work on making it easier to search for entities other than Items in the search box (phab:T338483)
  • Query Service: We set up the constraint checks to use the split graph instead of the full graph (phab:T374021)
  • Integration in the other Wikimedia projects: We are looking into how changes from Wikidata are represented on the other Wikimedia projects and how that can be improved (phab:T386200)

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

Vector-2022

[edit]

Oh I see that the transition from Vector to Vector-2022 has just happened. I'd like to welcome dark mode when it will come also in items. -- ZandDev (talk) 20:46, 17 March 2025 (UTC)[reply]

@ZandDev: I'm sorry, could you clarify what you mean?StarTrekker (talk) 20:52, 17 March 2025 (UTC)[reply]
@StarTrekker: phab:T387154 got deployed. -- ZandDev (talk) 21:11, 17 March 2025 (UTC)[reply]
I have dark mode enabled, but items show up in the usual (white) mode. Ymblanter (talk) 21:00, 17 March 2025 (UTC)[reply]
@Ymblanter: Yes, it is temporarily disabled because it is actually buggy with Wikibase, see phab:T369385. But I hope that in short time dark mode will land also in items. -- ZandDev (talk) 21:16, 17 March 2025 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2326547768"