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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Wikidata project chat
A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

For realtime chat rooms about Wikidata, see Wikidata:IRC.
Start a new discussion
Edit
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/05.

Ability to revert batch edits appears broken[edit]

See Wikidata_talk:Edit_groups#Not_working?. Sdkb talk 18:54, 17 April 2024 (UTC)[reply]

Umm, why isn't this causing alarm? Sdkb talk 17:18, 19 April 2024 (UTC)[reply]
Yes, I am sorry that I haven't been able to fix that yet. I have looked into the problem some weeks ago but did not have enough time to find out what the problem actually is. Superficially, it seems that the tasks queue (stored in redis) is behaving weirdly, with Celery (the tasks runner) not reliably picking up the tasks that are sent to it from Django (the web frontend). If anyone is interested in debugging this I would be very happy to give them access to the Toolforge project. The architecture of the tool is rather thoroughly documented, but I am well aware that that alone doesn't make co-maintainers rush to help. It's a fairly standard stack (even documented on Wikitech) but not one that's so widespread in Wikidata tools as far as I know. I have applied all dependency updates yesterday in the hope that it resolves itself but that was probably not enough. − Pintoch (talk) 07:51, 24 April 2024 (UTC)[reply]
@Pintoch: if you give me access I'll take a look. no promises I'll fix it though. User account is https://toolhub.wikimedia.org/search?author__term=BrokenSegue&ordering=-score&page=1&page_size=12 BrokenSegue (talk) 16:39, 25 April 2024 (UTC)[reply]
@BrokenSegue: thanks a lot! You're in. − Pintoch (talk) 22:00, 26 April 2024 (UTC)[reply]
@BrokenSegue, Sdkb: I've switched from one redis database to another and it seems like it improved things. I think the proper solution would be the proper prefixing of redis keys: https://github.com/Wikidata/editgroups/issues/89. − Pintoch (talk) 07:33, 1 May 2024 (UTC)[reply]

Pages that mis-identify[edit]

I'm new to the community and processing WikiData locally. One utility index I built goes from enwiki titles to WikiData items and back. Running this script over all of WikiData revealed 40 "Key conflicts": two WikiData pages that link to the same Wikipedia article.

One really odd type of key conflict is posed by pages like https://www.wikidata.org/wiki/Special:EntityData/Q20203111.json which claims to be Q118874608; a perfect duplicate.

Can anyone shed light on this? The full list: https://pastebin.com/MunHZjWP AdamVcoding (talk) 16:23, 30 April 2024 (UTC)[reply]

Nothing misindentifies here. The situation is easily understood by looking at the actual items in the Wikidata UI and looking at the item history.
Sitelinks sometimes get moved from one page to another and if your data is out-of-sync this means you won't end up at the same page in every case.
Q20203111 is a redirect and behaves like a redirect is supposed to act. ChristianKl ❪✉❫ 17:04, 30 April 2024 (UTC)[reply]
Thanks for elaborating Christian! Is there a mapping of redirects available?
In other words, where does the information (including the redirect notice) at https://www.wikidata.org/w/index.php?title=Q20203111&action=info live?
I made the assumption my version coincided with the live version on this weird subset, but mine still lists `"id": "Q20203111"`.
Nonetheless, I'll (locally) merge the pages with the same enwiki links like Q703702 (since the enwiki link has been removed) and Q125399268. AdamVcoding (talk) 17:57, 30 April 2024 (UTC)[reply]
Did you read the page? It seems to me like the information on it is pretty straightforward.
As I said above, sometimes the claim is just moved from one page to another. While merging a redirect with the page toward which it's pointing makes sense it does not make sense when the link moves from item A to item B. ChristianKl ❪✉❫ 23:43, 1 May 2024 (UTC)[reply]

Wikidata disambiguation pages[edit]

We currently create Wikimedia disambiguation pages if a disambiguation page exists in Wikipedia. Do we ever create a Wikimedia disambiguation page at Wikidata even if none exists at Wikipedia? We have more people needing diasambiguation at Wikidata since our inclusion criteria is more generous. See for example: Jeremiah Creedon (Q125707529). Is there anything that can be added to help someone looking for the correct one to easily see which one is the one they are looking for without clicking on each link or hovering the cursor? RAN (talk) 18:56, 30 April 2024 (UTC)[reply]

The description field can be used for disambiguation on Wikidata. I believe that disambiguation items on Wikidata should only exist if there is a corresponding disambiguation page on one of the other Mediawiki projects (see guidelines). Dogfennydd (talk) 21:51, 30 April 2024 (UTC)[reply]

Properties on Wikimedia list article (Q13406463) items[edit]

Is there a WikiProject guideline or past discussion that details what properties should be used with these items? There have been many recent batches that added country (P17) to thousands of list items (example: https://www.wikidata.org/w/index.php?title=Q115767416&diff=2141785849&oldid=1986343405), and has part(s) (P527) is often used too. My understanding is that instance of (P31), is a list of (P360) and category related to list (P1754) are pretty much the only ones that should be used? Xezbeth (talk) 09:18, 1 May 2024 (UTC)[reply]

I think P361 and P527 are correct in lists such as list of aircraft beginning with M (Q6605098) where a list is on multiple pages and the parts are sections of a list, or a list is composed of multiple lists; not sure about Gallery of the Royal Saxon milestones (Q1491902) where the parts are members of the list. Peter James (talk) 12:37, 1 May 2024 (UTC)[reply]
Generally, Wikidata is quite open with different properties being used and I can't think of an example where I would say that only a few properties can be used. Wikimedia list article (Q13406463) itself does have a few properties for this type (P1963) statements which suggests that country (P17) is quite proper. ChristianKl ❪✉❫ 23:50, 1 May 2024 (UTC)[reply]
The item is supposed to be specifically about the Wikipedia list and not what is actually being listed. How can a non-physical arbitrary list of stuff be physically in a given country? —Xezbeth (talk) 05:03, 2 May 2024 (UTC)[reply]

Jack Hall/Sam Hall Q6112885 Q2216488[edit]

In 2022, the enwp article Jack Hall (song) was moved to Jack Hall (highwayman), and the scope of the article changed from the song to the person it was about, as there was already an article about the song at Sam Hall (song) (the title of the song was originally "Jack Hall", but "Sam Hall" is now more frequent, and its common name; it's considered the same song by secondary sources, and has the same Roud Index folk song identifier).

But the Wikidata item Jack Hall (Q6112885) hasn't been changed, and so is still about the song. I was considering removing the enwp article on that item (and the link to Hall, John (d.17Dec1707) (DNB00) (Q19020924)), and merging it into Sam Hall (Q2216488), before creating a new item for the person, but wasn't sure what to do with the Freebase ID, and thought I'd check here first. Yodin (talk) 15:48, 1 May 2024 (UTC)[reply]

Need to merge[edit]

Please merge Q123160974 into Q503592. According to Wikipedia links, both refer to the same topic. Massol1360 (talk) 17:21, 1 May 2024 (UTC)[reply]

It looks like one is about the brand and one is about the (defunct) company that used the brand, so I think they should probably stay separate. Perhaps the article links should be rationalised, though. M2Ys4U (talk) 17:44, 1 May 2024 (UTC)[reply]
This should not be merged at all. Now it's part of P&G but who knows wether the'll keep the brand or sell it in some years. Matthiasb (talk) 12:18, 6 May 2024 (UTC)[reply]

English descriptions on Parliamentary and Assembly Constituencies of Tamil Nadu, India[edit]

Parliamentary Constituencies and Legislative Assembly Constituencies of Tamil Nadu (Q1445), India items descriptions are different from other Indian constituencies items. I feel that this does not follow the guidelines, Such descriptions allowed? Examples: Q4708203, Q3534197 (I also posted in Telegram Wikidata)Sriveenkat|talk/{PING ME} 02:05, 2 May 2024 (UTC)[reply]

Changing P5715 to be an Identifier[edit]

At the moment, for any Entities in which P5715 is used, the URL displays in the main section of the page, not under the § Identifiers heading. Either the Property could be changed so that it is put into the proper section of the page, or the property form of the URL could be transformed into the form of an ID, in the format of P6262. In that case, https://huji.academia.edu/LeeMordechai would become huji:LeeMordechai, https://stanford.academia.edu/GracielaChichilnisky would become stanford:GracielaChichilnisky, etc.


Thoughts? BhamBoi (talk) 04:03, 2 May 2024 (UTC)[reply]

seems like it would make sense BrokenSegue (talk) 05:06, 2 May 2024 (UTC)[reply]
While it is possible to have IDs consisting of two parts, I think the reason why this is not done here is because the url formatters can't do anything fancy like constructing urls based on different parts of the ID. Infrastruktur (talk) 10:52, 2 May 2024 (UTC)[reply]
I believe Wikidata External ID redirector (Q108047563) has the ability to do that, but it's been some time since I've looked at that tool. But I would be cautious about making any breaking changes because the property is used by templates on other projects that could be broken. William Graham (talk) 15:42, 2 May 2024 (UTC)[reply]

Feedback period about WMF Annual Plan for 2024-25 is open![edit]

Hello everyone! The work of the Wikimedia Foundation is guided by its Annual Plan. We’ve now published the full draft Annual Plan on Meta. Please share your feedback and ideas!

This is really one of the best chances to influence how the Wikimedia Foundation works and what it chooses to focus on and prioritise, as the Annual Plan is the main guiding document for planning what to do. This is a high-level document, as it aims to find the key points for the entire organisation – this is to find the main direction, which will help the teams at the Wikimedia Foundation to find more tangible objectives.

These are the main goals:

You can read more about what this means in practice on Meta, where you can find both summaries of what the Wikimedia Foundation wants to achieve and links to more detailed pages.

You’re very welcome to share your thoughts on Meta or here, in your own language, and we’ll make sure they are passed on to the relevant parts of the Wikimedia Foundation and that your questions are answered. We can also set up meetings in your own language to further discuss the implication of the Annual Plan, if needed.

Thank you very much for your participation! Sannita (WMF) (talk) 10:23, 2 May 2024 (UTC)[reply]

Incorrect data[edit]

the data on Stephen Wombwell is incorrect 92.207.153.221 12:37, 3 May 2024 (UTC)[reply]

I am guessing from the edit history of your IP address that you mean Stephen Philip Henry Wombwell (Q76219282) rather than Stephen Frederick Wombwell (Q55587569). What data are you disputing? The previous edit from your IP to delete a statement in 2022 (without explanation) is not good practice. The statement will probably be restored unless there is a sound reason. From Hill To Shore (talk) 14:25, 3 May 2024 (UTC)[reply]
Stop the presses then! I'm gobsmacked, flabbergasted and dumbfounded that there be incorrectnesses found in Wikidata. I hope you can find it in your heart to forgive us for our inadequacies good sir. On the other hand... what are we talking about? Infrastruktur (talk)

Property proposal[edit]

Please, I propose that property Photopickly ID gets created and added to Q65275317 as a reference URL from Wayback Machine (qualifier): part for a qualifier of URL https://archive.is/eugr1 /Please, note that item's YouTube channel contains most-upper banner text similar to i.e. Photopickly so add that property to the item in question. I've just added Property:4576 (difference between revisions: https://www.wikidata.org/w/index.php?title=Q65275317&diff=2143621493&oldid=2143612683 Special:Diff/2143612683/2143621493). Please; note that there is one music project present among or between other nine (7th by order) and it is not clearly visible what text is written there; I have just seen better, it is Amazon and is already present as first identifier item has.

Check: http://web.archive.org/web/20240503124935/https://www.youtube.com/channel/UC-TkhwZkQitPvJ0GV0IJeKA versus http://archive.is/kFhEK (a channel exists). --77.221.2.19; 13.52, 2024-05-03 (UTC)

Note that property creation process is described here. An anonymous Project Chat post is not enough to create one. --Jklamo (talk) 09:38, 5 May 2024 (UTC)[reply]

Géopatronyme ID (P3370)[edit]

Géopatronyme ID (P3370) links such as http://www.geopatronyme.com/nomcarte/PETIOT now redirect to an error message at https://en.filae.com/v4/genealogie/errorpage.mvc/errorpage404 I think the correct URL for this example is https://en.filae.com/v4/genealogie/search.mvc/searchform?ln=PETIOT&tab=0&idf=False&hmtr=True&gmsr=True Filae (Q86668676) has a Q number, but no Filae ID property exists. Some information at Filae is shown for free, but you need to pay for a subscription in order to see most of the information. Eastmain (talk) 19:32, 3 May 2024 (UTC)[reply]

Point-in-time localization[edit]

What is used to format point in time (P585), publication date (P577) and similar in languages other than English? For Croatian, https://www.wikidata.org/wiki/Q1413796?uselang=hr#P1082 should be 31. kolovoza 2021. instead of 31. kolovoza 2021 (years are ordinals and should end with a dot) Ponor (talk) 21:22, 3 May 2024 (UTC)[reply]

This would be better be reported in Phabricator. I can see Croatian already has definitions for its date format, perhaps the system uses the "default" (whatever it is)? --Matěj Suchánek (talk) 09:06, 5 May 2024 (UTC)[reply]

Property proposal 2[edit]

Add musicboard.app as MusicBoard ID property. Example of needed usage: Q125764902 needs 139337739. --77.221.2.19; 23.27, 2024-05-04 (UTC)

Property proposal 3, 4, 5, 6[edit]

Add festivaly.eu as FestivaliEU ID property. Example of needed usage: Q125764902 needs 1449800.

Add www.kkbox.com as KKBox ID property. Example of needed usage: Q125764902 needs HYhuDl2oa-MNXufeYp.

Add thirdeyemusic.co.uk as ThirdEyeMusic ID property. Example of needed usage: Q125764902 needs Uroš_Živković.

Add www.viberate.com as Viberate ID property. Example of needed usage: Q125764902 needs uros-zivkovic.

--77.221.2.19; 23.46, 2024-05-04 (UTC) [e]

Vatican/Holy see[edit]

Hi, when it comes to country (P17) value, should we use only Vatican City (Q237) and not Holy See (Q159583) ? I'm wondering. Bouzinac 💬●✒️●💛 06:31, 4 May 2024 (UTC)[reply]

TIL; The english Wikipedia suggests the Holy See is the combination of the diocese of Rome and the city-state Vatican. Infrastruktur (talk) 07:30, 4 May 2024 (UTC)[reply]
Actually, the Holy See and the Vatican are two different subject of international law (Q1896989), with both of them members of the United Nations. However the Vatikanstadt (P237) is the state. Don't see reason for rejcections in P530. Matthiasb (talk) 12:12, 6 May 2024 (UTC)[reply]
Holy see is not full member of U.N. https://www.un.org/fr/about-us/non-member-states
Vatican is not listed https://www.un.org/en/about-us/member-states#gotoV Bouzinac 💬●✒️●💛 20:56, 6 May 2024 (UTC)[reply]

Create a EntitySchema creator user rights group[edit]

Hi, I suggest creating a EntitySchema creator user rights group (just like property creator user rights group, but it can use Special:NewEntitySchema to create new EntitySchema).

We have Wikidata:Schema proposals now, and it says "Schemas are created through discussion with the community, which helps to consider a wide range of use cases and contexts. The new Wikidata Schema will be created once the community reaches consensus about the correct model to use. " We may use this page to discuss new EntitySchema (after a new EntitySchema creator user rights group created.)--S8321414 (talk) 13:20, 4 May 2024 (UTC)[reply]

Do you see any problems that are currently produced by people creating EntitySchema's in a way that such a process would prevent? It was my impression that the main problem with EntitySchema's is a relative lack of engagement with them and not overeager creation of them.
It's also worth noting that Wikidata:Schema proposals is not something that came out of a community debate that ended in a consensus. ChristianKl ❪✉❫ 21:52, 4 May 2024 (UTC)[reply]
Some example like E427 (no meaningful information) and E430 (deleted, invalid EntitySchema). They are created not based on community consensus and not used for any case.--S8321414 (talk) 23:41, 4 May 2024 (UTC)[reply]
It does kind of seem like unnecessary bureaucracy. If there is low engagement, adding another barrier to entry is probably not what we want, at this point in time at least. It was probably meant to model property proposals, but that was something that was established because having properties added willy-nilly would be long-term damaging to the database, so having a gatekeeper function made sense. Worst case here is someone creates an entity schema that is low-quality or isn't used. There are other ways to compensate for this. You could make it easier to delete entity schemas, you can add a quality classification to them (high, medium, low, unassessed), you can also prevent unconfirmed users to create them with an abuse filter. Is there some support for a filter? Infrastruktur (talk) 08:50, 5 May 2024 (UTC)[reply]
Should be good to prevent unconfirmed user creating EntitySchema, other method may not be necessary for now.--S8321414 (talk) 11:51, 5 May 2024 (UTC)[reply]
Yes, preventing unconfirmed users from creating them seems like a good solution. ChristianKl ❪✉❫ 19:57, 6 May 2024 (UTC)[reply]

Propery proposal 7[edit]

Add music.youtube.com as MusicYT ID property. Example of needed usage: Q551335 needs UCW-tVFyrwYL9NdLXbltL04w. --5.43.76.87; 09.32, 2024-05-09 (UTC)

country or country of origin for intangibles like organisations or websites[edit]

For websites, and organisations, should country (P17) or country of origin (P495) be used? For organisations that have physical headquarters, then country (P17) could make sense, but so many organisations, or websites that have no clear organisation behind them, are purely virtual and are much closer to an intellectual idea like a book or product when country of origin (P495) would be used. I think my preference is the latter. Vicarage (talk) 13:02, 5 May 2024 (UTC)[reply]

Actully this property is a term of customs, Champagne comes from France, Kuckucksuhren from Germany, Wiener Würstchen from Vienna, Austria (except for those from Frankfurt am Main, but that's another story). Unfortunately the German description includes only creative works as in arts. Which is only part of it.
However, for organisations P17 should be used. Not sure for websites. Matthiasb (talk) 12:04, 6 May 2024 (UTC)[reply]

area = 15,476046301239837 km²[edit]

Some municipalities in Norway, e.g. Grimstad (Q90590), Ullensaker (Q57917) (I would suspect most, if not all in municipality of Norway (Q755707) [1]) have in their area (P2046) truly precise values, I checked one, it was by User:Jeblad (bot) not active any more. Now 15.476046301239837 km² = 15476046.30124 m² or 154760463012.4 mm². What is demonstrated here, is a deep non-understanding of sound measurements and sound realistic precisions in a physical context. There are refs, but they lead to a general page (maybe someone can check whether these figures are from that website). Nobody can measure the area of ice (Q23392), snow (Q7561), glacier (Q35666), lake (Q23397), river (Q4022), forest (Q4421), bog (Q1681353) to that precision (fractions of square mm). And if, you have to give the timestamp in fractions of millisecs. Does Wikidata have an educational mission? Should we copy the dumbness of the world into wikidata? Copying data 1:1 from any source might be convenient, but rounding to that extent cannot be the burden of the user of these data. IMHO we need defined maximum precisions in certain contexts, that make sense in the context and are applied automatically at least when showing, returning, etc these values (e.g. lengths of rivers, areas of communities, heights of mountains, lengths of coast lines, etc. etc.). Adding error intervals in general would be great. An area of a community, parts of the community, can be measured quite accurately from satellite, but fraction of square mm is beyond anything. Rounding need not skip any decimals, but just keep them in the intestines. Not showing, not returning.

Let me compare this to coordinate location (P625), where you can at least define a precision, but the default precision is Spezial (±1e-8°) (which makes me also wonder). At least you can define the precision, alas this will round / truncate the figures. best --Herzi Pinki (talk) 16:50, 5 May 2024 (UTC)[reply]

I understand precision issues well, but I can't be bothered to pick a sensible number of decimal places when copying someone else's values into coordinate location (P625), often because they are the result of a calculation. I expect areas are the same. I always assume a bot will sort it out. When I query the same data I do apply a sig fig filter before displaying it because it bugs me like it does you. But an education campaign and obsession over the raw data seems misplaced. Perhaps WD could have user preferences for display precision. Vicarage (talk) 18:30, 5 May 2024 (UTC)[reply]

Is it really an item of class Q618779?[edit]

I see the problem here. Honoris causa is in fact not an item but property: it is not a separate award or degree but a sort of some awards/degrees. A person might hold the degree of Q752297, Q2248352, Q837343, Q17379493 and so on assigned to them honoris causa, i.e. without providing required thesis etc. So I would argue that this is in fact an item of class Q189533, and the proper use of it for the persons must be as a qualifier for any of aforementioned (and some other) degrees within the property academic degree (P512){{{2}}}{{{3}}}. Андрей Романенко (talk) 12:14, 25 April 2024 (UTC)[reply]

Moved from Talk:Q209896, since this is a general issue. Ymblanter (talk) 18:38, 5 May 2024 (UTC)[reply]
seems like it's both an award and a kind of degree BrokenSegue (talk) 19:08, 5 May 2024 (UTC)[reply]
This kind of degree is an award (as distinct from any regular degree). But the award is not just "honoris causa", the award is "doctor of science honoris causa". Андрей Романенко (talk) 19:32, 5 May 2024 (UTC)[reply]

Could we switch the default interface skin to Vector 2022?[edit]

The current default interface skin is Vector 2010, which is now legacy. I've been trying the new Vector 2022 skin here for a while now, and it seems to be working well. You can try it by changing the interface at Special:Preferences#mw-prefsection-rendering. Are there any issues here that could prevent us from changing the default? Would it need a vote here, or should we just submit a request to make the change? Thanks. Mike Peel (talk) 19:55, 5 May 2024 (UTC)[reply]

I've been trying it out since you started this thread. My one bugbear with it is that the site links are all moved to the bottom of the page to make room for the new side bar. From Hill To Shore (talk) 08:48, 6 May 2024 (UTC)[reply]
I dislike it for the same reason and others, and manually select the 2010 version on all wikis I use. Changing it will effect everyone's custom JS/CSS, but I don't know what features there might break. Vicarage (talk) 09:07, 6 May 2024 (UTC)[reply]
The sitelinks move down when the page is too narrow, on all themes I believe. On my laptop screen, if I have the left-hand menu minimised (there's a switch for this), then the sitelinks appear at the top of the page for me. Thanks. Mike Peel (talk) 12:27, 6 May 2024 (UTC)[reply]
It seems to be a flawed implementation with Wikidata. I can only get the site links into the correct position if I set my 1920*1080 screen to "full width" (option within the Vector 2022 skin) and turn one of the side menus off, or I keep the screen in normal width and turn off both side menus. If the point of having the new skin is to include the two sidebar menus but you need to turn the sidebars off to correctly display the primary material on the page, where is the benefit over the old skin?
It would be useful to see if there are other editors who experience similar problems with different screen sizes. From Hill To Shore (talk) 15:07, 6 May 2024 (UTC)[reply]
With my 2560x1440 Linux Mint display I can get site links only if I disable "limited width" mode. But then the text is too small for comfort. I prefer the limited width display with a single toolbar, as I can boost the font size more. Vicarage (talk) 20:43, 6 May 2024 (UTC)[reply]
As far as the process goes, having this conversation open for a week seems enough for me so that anyone who might complain has the change to object. ChristianKl ❪✉❫ 11:27, 6 May 2024 (UTC)[reply]
Considering there are a lot of links to Wikidata pages in Russian Wikipedia, I think forcing the new interface without adapting it to the needs of Wikidata first (by having interwiki links higher etc.) is plainly unacceptable. I strongly oppose this proposal. stjn[ru] 22:29, 6 May 2024 (UTC)[reply]

A new item was deleted, I need help with undeleting it and unblocking my user[edit]

@User:Pi.1415926535

I recently uploaded a few items on wikimedia commons and wikidata.

It was marked as spam and deleted.

One was a page about an award winning author, a media company that supports Non profits and a healthcare agency.

There was no sign of advertising or soliciting.

I'm a new user, please help me navigate to unblock and undelete the posts.

Thank You PRWithSagar (talk) 08:08, 7 May 2024 (UTC)[reply]

One generally starts by asking the person deleting for an undeletion. You can find more information at Wikidata:Guide to requests for undeletion, Commons have their own policies. I note that your talk page privileges were disabled on Commons, which is something that's usually not done at least on Wikidata unless the talk page have been abused or there is reason to suspect that it will be. Infrastruktur (talk) 13:32, 7 May 2024 (UTC)[reply]
Commons blocking policy says, "Only prevent the blocked user from using their talk page or sending e-mail if they are likely to abuse these privileges." I don't see any indication of that in this case, but maybe I'm missing something. Regardless, we can't do anything about a Commons block here. Bovlb (talk) 18:20, 7 May 2024 (UTC)[reply]
@Bovlb and Infrastruktur: See my reply here. TL;DR: spammers tend to abuse talk page access to continue spamming unless it is preemptively revoked. The Commons uploads were blatantly promotional. Pi.1415926535 (talk) 19:49, 7 May 2024 (UTC)[reply]
Ping @Ymblanter as deleting admin of Q125808243, Q125808543, Q125808616. At first glance, deletion was probably warranted (lack of notability) --Emu (talk) 14:20, 7 May 2024 (UTC)[reply]
Also cross-wiki spam according to the nomination. Ymblanter (talk) 14:37, 7 May 2024 (UTC)[reply]
I reviewed the three deleted items. None established notability. This appeal does not add any information that would establish notability. Bovlb (talk) 16:00, 7 May 2024 (UTC)[reply]

Wikidata weekly summary #626[edit]

Here's your quick overview of what has been happening around Wikidata over the last week.
This is the Wikidata summary of the week before 2024-05-06.
Translations are available.

Discussions

Events

Press, articles, blog posts, videos

Tool of the week

  • Wikidata periodic table - Tool by User:Ricordisamoa, to browse all chemical elements available on Wikidata, with atomic number, chemical symbol, and localized label. It also includes two charts of the nuclides, with links to every isotope in Wikidata, colored by half-life or decay mode.

Other Noteworthy Stuff

  • A new UI mode is available for the online validator for EntitySchemas. It represents validation reports as a table rather than a very long string, and replaces most links with hyperlinks with some of the text behind them; making them easier to read. Currently being tested at https://shex-validator.toolforge.org/packages/shex-webapp/doc/shex-simple-improved.html, we are looking for participants to evaluate this tool. Some experience with editing Wikidata is appreciated, but no experience working with Schemas is required. If you are interested, you can sign up here. We hope to begin interviews around May 13. For more details, visit User:M.alten.tue

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • We attended the Wikimedia Hackathon.
  • REST API: We are finishing the route for creating an Item (phab:T342990) and modify the data of a Property (phab:T347394)
  • EntitySchemas: We are continuing the work on creating the new datatype to link to EntitySchemas in statements (phab:T214884)

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

· Unsubscribe · Help translate · MediaWiki message delivery (talk) 10:59, 7 May 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2147940583"