Shortcut: WD:AN

Wikidata:Administrators' noticeboard: Difference between revisions

From Wikidata
Jump to navigation Jump to search
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
Ninakp (talk | contribs)
2 edits
Line 242: Line 242:


Please undelete the entry for Kaiman Lee on wikidata (Q126734059). More editing needs to be done. [[User:Ninakp|Ninakp]] ([[User talk:Ninakp|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 21:15, 19 June 2024 (UTC)
Please undelete the entry for Kaiman Lee on wikidata (Q126734059). More editing needs to be done. [[User:Ninakp|Ninakp]] ([[User talk:Ninakp|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 21:15, 19 June 2024 (UTC)
:{{question}} Have you consulted the [[WD:N|notability policy]]? If yes, could you elaborate a bit how you believe it meets the notability requirements? --[[User:KonstantinaG07|KonstantinaG07]] ([[User talk:KonstantinaG07|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 22:15, 19 June 2024 (UTC)

Revision as of 22:15, 19 June 2024

Unblock request for TheBellaTwins1445

I invite wider review of the unblock request at User talk:TheBellaTwins1445. We've been awaiting a response from @Jasper Deng, the blocking admin, but they seem to be taking a wikibreak. Bovlb (talk) 16:45, 24 May 2024 (UTC)[reply]

This is a checkuser block so only checkusers are allowed to handle it. Their Commons user talk page paint a picture of someone who years ago repeatedly disregarded rules, blatantly lied in their unblock request and evaded their block. Didn't dig that deep into the sock drawer, but they have lots of contributions on spanish wikipedia and also a clean block log there. I noticed a comment from Madamebiblio on their spanish user talk page 27 Jan 2024 about them editing Wikidata as an IP-user whilst blocked here. The timing of the Wikidata unblock request relative to this comment seems, shall we say convenient. Infrastruktur (talk) 20:34, 24 May 2024 (UTC)[reply]
The block reason does not explicitly state that it was a checkuser block. I am unable to find it right now, but I seem to recall a discussion a few months ago where Jasper Deng specifically stated that we should not consider their blocks to be checkuser blocks unless they explicitly say so.
That's useful background information, and I'm certainly not entirely convinced myself, but I'd entertain an unblock in this case per en:WP:ROPE. Bovlb (talk) 20:49, 24 May 2024 (UTC)[reply]
For what it's worth, I'm familiar with the user's work on eswiki and consider them to be productive there. IIRC, the unblock request came about because they asked for assistance with a Commons picture (to be used in an eswiki article they were working on), and the responding admin suggested they appeal their blocks instead. I would be inclined to unblock per ROPE as well. –FlyingAce✈hello 20:58, 24 May 2024 (UTC)[reply]
The original block reason on Wikidata was for replacing images with their own work using several accounts. Seems reasonable they should be given a second chance, since issues were localized to Commons or Commons-related. Infrastruktur (talk) 22:55, 24 May 2024 (UTC)[reply]
He's an user who historically used sockpuppet accounts and has evaded his block until this year on different projects (See 1 and 2). On Wikidata he continued to edit from IPs until after my January message. I can make an infinite list of IPs used here.
His editing behavior: he tries to impose his editions, generates edit wars and has a lots of warnings from ESwiki administrators.
In particular, I still don't trust him enough. Madamebiblio (talk) 15:23, 25 May 2024 (UTC)[reply]
  • To be clear, this is not a CheckUser block. CheckUser blocks are always marked explicitly as such. Therefore, any admin can review it. However, given Madamebiblio's comment, I am not in support of an unblock without explicit concrete examples of constructive contributions they wish to make (their existing comment is too vague, and conflates "articles" with items and properties).--Jasper Deng (talk) 06:20, 26 May 2024 (UTC)[reply]
    One week passed after application. Application rejected by me Estopedist1 (talk) 06:28, 27 May 2024 (UTC)[reply]
    That seems premature, given that discussion here is ongoing and does not clearly show a consensus in that direction. Bovlb (talk) 17:06, 27 May 2024 (UTC)[reply]
    I have to concur, the request had been open for a week but discussion here had only been going on for 3 days. –FlyingAce✈hello 00:43, 28 May 2024 (UTC)[reply]
    @Bovlb@FlyingAce: if an user in question has used over 20 alternative accounts (see Commons:Category:Sockpuppets of TheBellaTwins1445), then I don't think there is much to discuss Estopedist1 (talk) 15:21, 28 May 2024 (UTC)[reply]
    @Estopedist1: if we are going to take into account their status in other projects, then I think we ought to consider that they are a user in good standing on the Spanish Wikipedia. More to the point, is there evidence of recent socking? I see that they were warned regarding logged out editing earlier this year, so that is a point against unblocking now, but I don't think it is fair to state that an unblock will never be possible in the future. –FlyingAce✈hello 15:39, 28 May 2024 (UTC)[reply]
    in general, such kind of human types do not change, but given the huge contributions in eswiki (besides a lot of discussion also in eswiki at his talk page) I am open to withdraw one's unblocking refusal and to apply en:WP:ROPE Estopedist1 (talk) 15:51, 28 May 2024 (UTC)[reply]
    I would prefer to wait to unblock him (if he doesn't end up blocked on ESwiki next time: last messages on ESwiki talk page are warnings from admin and he's already blocked in two other projects). Will any sysop going to be responsible for monitoring his activity on Wikidata? One possibility is to invite him to request a new unblock in the course of the next six months: if his record is clean he'll be unblocked. Madamebiblio (talk) 16:46, 28 May 2024 (UTC)[reply]
    I would not propagate unblocking. User has had many sockpuppet accounts on various Wikimedia projects. Many of the socks, for instance among the ones mentioned at Commons, have made edits here, while their socking here remained unnoticed. In view of that, their user talk page message does not really convince me. I would expect them to reveal all socks they have used, in order that those can be blocked here, also ones that escaped our attention. That might yield some trust in seriousness of their future behaviour. --Lymantria (talk) 19:41, 28 May 2024 (UTC)[reply]
    This sounds good to me. I now think it's best to not unblock now, but the possibility of a future appeal should be left open; however, any future request should address the sockpuppetry. –FlyingAce✈hello 21:25, 28 May 2024 (UTC)[reply]
    The question we have to answer is: Is this block necessary to prevent disruption to the project? I don't mean to encourage socking, but I don't think this block is really preventing them from contributing here; instead it's preventing them from contributing in an honest and straightforward way. Keeping the block will not prevent socking; it might even encourage it. If we unblock, and it results in disruption, then that will resolve the question simply and clearly. We can block, revert, and move on.
    Regarding the two recent admins warnings on ESWP, at least one seems to be concerned with them asking others to help them make presumably constructive edits to Wikidata on their behalf. This is a violation of policy, but one that wouldn't exist if we lifted this block. Bovlb (talk) 01:08, 29 May 2024 (UTC)[reply]
There have been people blocked for a good reason before who made useful contributions. If you go looking for reasons to keep them blocked I'm sure you will find them. Fortunately the ROPE philosophy doesn't require trust, it simply asks if the possibility exists that the user in question can become a rule-abiding contributor. Rather than a lengthy unblock ordeal it rests on the user to prove that they belong. For the kind of users this is applied to it should be evident soon enough. I'm kind of ambivalent but I do think this is a ROPE candidate. Infrastruktur (talk) 20:12, 30 May 2024 (UTC)[reply]
Discussion seems to have petered out, and there's not an overwhelming consensus one way or the other, so in an effort to reach a concrete resolution, let's try a !vote.
✓ Unblock per ROPE and evidence of constructive editing on Spanish Wikipedia. Bovlb (talk) 22:11, 4 June 2024 (UTC)[reply]
Sounds good to me. After some consideration, I am leaning towards an ✓ unblock since the recent logged-out editing was not an attempt to avoid scrutiny, but rather to fix issues arising from their regular editing on eswiki. –FlyingAce✈hello 22:32, 4 June 2024 (UTC)[reply]
Unblock and monitor, happy to give a second chance here. -- Ajraddatz (talk) 01:06, 5 June 2024 (UTC)[reply]
 Neutral: I as a blocker. I am out of this discussion, unable to analyze Spanish-language edits--Estopedist1 (talk) 06:55, 5 June 2024 (UTC)[reply]
 Oppose: edits on ESwiki affect only that project, what happens on Wikidata affects all Wikipedias and this project. Linking articles and completing the infobox can be done locally on ESwiki; on ESwiki he hoards articles and imposes edits. On Wikidata: for one year he edited with impunity via IPs while blocked until I publicly unmasked him (he ignored reversals and edit messages). And continues to be blocked (without unblocking request) on Commons and ENwiki. Madamebiblio (talk) 05:08, 6 June 2024 (UTC)[reply]
 Oppose Not convinced, I've not seen enough reflection on use of socks. I am not a fan of ROPE in this project. A sock alongside neat behavior of the released master account can very easily exist here without being noted. --Lymantria (talk) 05:29, 6 June 2024 (UTC)[reply]
OK. Good points have been made on both side. Numerically, there seems to be a slight edge to "unblock", but I'm not seeing a clear consensus to override the block. My advice to the @TheBellaTwins1445 would be to wait at least six months and come back with strong evidence of good contributions on other projects. Sorry. Bovlb (talk) 16:31, 12 June 2024 (UTC)[reply]

TemirovBot

No real big deal but it seems TemirovBot is (was?) massively adding statements with wikicode in the title of the source, a wikicode formatted reference with a template, entirely in the title property field. See for example this edit : https://www.wikidata.org/w/index.php?title=Q19642583&curid=21244550&diff=2174354453&oldid=1756748655

@Игорь Темиров: author  TomT0m / talk page 11:50, 8 June 2024 (UTC)[reply]

I'm migrating the population database from Ruviki to wikidata. About 600 thousand observations. Output supported by template Population. I have not found a single way to correctly display links in articles, other than placing templates in the title field. Other language sections may handle in their own manner. Игорь Темиров (talk) 12:29, 8 June 2024 (UTC)[reply]
@Игорь Темиров: This cannot work like that, this would mean that, say on frwiki, the templates you use does not exists, so trying to display the reference for the statements would display an error.
There are ways to display Widata statements as references on Wikipedias, the "Cite Q" module is one Module:Cite Q (Q33429959)  View with Reasonator View with SQID — you can create an item for one (or all) very cited reference in your list for example, add the relevant statements to the item, use it in a reference with "stated in (P248) View with SQID". The "cite Q" module should not be very hard to import.
You can also adapt functions like this one (of the Wikidata frwiki lua module) that uses the relevant properties of a statement reference to add display it. author  TomT0m / talk page 13:05, 8 June 2024 (UTC)[reply]
@TomT0m: Yes, thanks, I know about these modules. But, unfortunately, none of them correctly displays information about links if they include, for example, an archive on the Internet and the like.
(you forgot to sign) @Игорь Темиров: This can be solved, you should import the data correctly anyway, and deal with the problems with templates afterward. See the enwiki cite Q Module includes code to deal with archive url Search, for example, if there is a bug you may discuss it in the talkpage for help on how to solve this. author  TomT0m / talk page 13:48, 8 June 2024 (UTC)[reply]
I am planning to do what you are talking about after migrating the data Игорь Темиров (talk) 14:21, 8 June 2024 (UTC)[reply]
@Игорь Темиров: You mean, import the source data all in the title field for them to be displayed OK on ruwiki and avoid seeing errors or display issue on ruwiki, at the expense of having errors or display issues in all other wikis and external data reusers. There may be many many over reusers than the "population" template, infoboxes for example, also the "article placeholder" extension, see Q19642583  View with Reasonator View with SQID on nnwiki for example. There is an open list of problems where this can go wrong. This is very bad practice.
Then parse the template to extract the field and put them properly on Wikidata and setting a correct title, a correct external url and so on, so correcting the errors everywhere else only afterward ? I don't think it's an acceptable thing to do. It seem easier to import the data correctly in the first place, that to re-parse the template afterward and redo a whole bot run.
It's more work to do in the end the way you do it, what's the rush ? author  TomT0m / talk page 14:45, 8 June 2024 (UTC)[reply]
Yes, you are right. Naturally I would think so. But, again, due to poor display of reference, I went this route. But even in this case, Q19642583  View with Reasonator View with SQID on nnwiki does not look fatal. Игорь Темиров (talk) 14:54, 8 June 2024 (UTC)[reply]

Side-notice: also related problem in this noticeboard: Wikidata:Administrators'_noticeboard#User:TemirovBot--Estopedist1 (talk) 06:12, 12 June 2024 (UTC)[reply]

Request for protection of Q126171758 and Q126047522

Edit-warring. —— Eric Liu（Talk） 15:50, 8 June 2024 (UTC)[reply]

@Ericliu1912, @Txkk: enwiki has pending discussion about merging/redirecting related to this Taiwanese event. Please discuss at enwiki (en:Talk:2024 Taiwanese legislative reform protests) or at Wikidata talk page (e.g. at talk:Q126047522) Estopedist1 (talk) 06:13, 10 June 2024 (UTC)[reply]
@Estopedist1: They're not trying to discuss. Besides, per discussion in Chinese Wikipedia, the related articles are still in the process of merging, thus the Wikidata sitelink should not be altered further more, unless there are clear consensus among communities. At this point, I kindly request temporary full protection of the status quo for both links. —— Eric Liu（Talk） 22:56, 12 June 2024 (UTC)[reply]
both fully protected for one month. Edit-warring and pending discussions in enwiki and zhwiki Estopedist1 (talk) 06:13, 14 June 2024 (UTC)[reply]

Report concerning JMagalhães

A user has been exhibiting disruptive editing behaviour, focusing on removing aliases and modifying genders. Here are some examples:

We can also see they are removing terms without including them on the alias in several other moments:

This behaviour is problematic for the following reasons:

  • Information Loss: Removing aliases hinders the searchability of entities with different names.
  • Disruption: Edit warring disrupts the collaborative editing process by repeatedly undoing other editors' work.

The core concern is removing information and edits warring, not just modifications. These actions violate established practices and confuse users relying on accurate and consistent information.

 Comment The fact that this account has been persistently pushing for controversial and/or blatantly wrong changes through edit warring, and then complains in this noticeboard posing as the victim is absolutely puzzling. The first half of the links are simply controversial changes being undone. That's it. Stop POV-pushing through edit wars and get consensus for the changes. The second half... I'm just clueless about whatever this editor is trying to prove or claim.

Beyond that, I would like to point out to administrators the systematic disruptive use of edit summaries by this account. Among its last 500 edits, 83 summaries are used to engage in personal attacks to users who simply undid one of his controversial changes or made some sort of edit he didn't like, systematically calling them "vandals" and "trolls". And this is not the first time this user opens blatantly nonsense incident reports. For example, last year he opened an absolutely bizarre and nonsense claim against me claiming, with no proof whatsoever, that I was "doing vandalism driven by sexism". Being an administrator myself for 10 years, I've dealt with many bizarre things, but this is hard to beat. I'm considering open a T&S case against this user because his claims are so outlandish and out of touch with reality that I'm afraid there's underlying issues that should be handled privately. JMagalhães (talk) 18:10, 9 June 2024 (UTC)[reply]

The fact that you attacked me, not defending your actions, says loudly about you. Also, it is not only me that you attack and enter into edit wars. It is not me who is removing information from Wikidata.
It is a clear no-posture when discussing his actions.
Moreover, this "his claims are so outlandish and out of touch with reality" should be enough for a long block. Attacks that no one should receive. Rodrigo Tetsuo Argenton (talk) 22:02, 9 June 2024 (UTC)[reply]

 Comment It has already been explained to this user that when his controversial edits are undone, he should not be pov-pushing through edit wars and should instead engage in consensus building. Yet, not only he keeps pushing unwanted edits and massively using summaries for personal attacks. But, in a bizarre move, he pretends to be some sort of victim and opens incidents reports with completely made-up stuff and claims that are beyond outlandish. Honestly, an administrator intervention would be nice to help this person return to reality. JMagalhães (talk) 10:00, 10 June 2024 (UTC)[reply]

Again, another attack in front of all admins, and nothing is done. Rodrigo Tetsuo Argenton (talk) 20:56, 12 June 2024 (UTC)[reply]

+2 days of impunity. Rodrigo Tetsuo Argenton (talk) 15:17, 14 June 2024 (UTC)[reply]

+ 2 days of impunity Rodrigo Tetsuo Argenton (talk) 05:16, 17 June 2024 (UTC)[reply]
+2 days of impunity Rodrigo Tetsuo Argenton (talk) 20:26, 18 June 2024 (UTC)[reply]

Report concerning User:Entranced98

Entranced98 (talk • contribs • deleted contribs • logs • filter log • block user • block log • SUL (for IP: GUC)) — Reasons: Unresponsive problematic user. After yesterday's warning and another several months ago, the user has not responded and continues to add descriptions that do not comply with Wikidata guidelines. Regards ―Kirilloparma (talk) 00:12, 11 June 2024 (UTC)[reply]

✓ Done Blocked for 2 weeks. It seems that a lot of repair work is to be done. I expect Entranced98 to carefully read the guidelines and start with repairing descriptions starting with an unneeded capital or ending with a comma, before adding new ones. --Lymantria (talk) 05:32, 11 June 2024 (UTC)[reply]

User:TemirovBot

This bot currently misuses title (P1476) property to add Wikipedia template syntax in Wikidata. This breakes the data for data consumers that use reference properties in proper manner. E.g. see Special:Diff/2176659938. Bot operator apparently does this intentionally, and doesn't intent to fix their bot (see User talk:Игорь Темиров#References not properly extracted from Wikipedia templates). I think this bot needs to be blocked and it's recent edits should be reversed. 2001:7D0:81DB:1480:E417:CFF3:ACEA:C1D8 21:04, 11 June 2024 (UTC)[reply]

yeah it appears this task was not approved and putting mediawiki syntax into wikidata is not proper. e.g. this edit [10]. I would block but it isn't running right now. @Игорь Темиров: please revert and seek approval for this task. BrokenSegue (talk) 23:48, 11 June 2024 (UTC)[reply]
I'm sorry. Today I will start redoing title (P1476) property. Игорь Темиров (talk) 06:07, 12 June 2024 (UTC)[reply]
@Игорь Темиров: if this is going to be a regular ongoing task with a lot of edits you should probably also seek approval in general BrokenSegue (talk) 04:54, 13 June 2024 (UTC)[reply]
No, this is a one-time task. Игорь Темиров (talk) 14:53, 13 June 2024 (UTC)[reply]
The day before yesterday I started replacing the templates in the “Title” field with the “Stated in” field. Игорь Темиров (talk) 10:39, 17 June 2024 (UTC)[reply]

Make edits to protected entity Project:Administrators Q4039395

I made a request onthe talk page to edit Project:Administrators to associate it with Q4656150 (and provided a reference), but cannot make the edit myself because the page is protected. Can someone with rights please make this edit? Thanks! Zarinek (talk) 20:48, 14 June 2024 (UTC)[reply]

 Not done: disputable, answered at Talk:Q4039395 Estopedist1 (talk) 06:22, 17 June 2024 (UTC)[reply]

Still ✓ Done by user:Benjamin Mako Hill. Now, I am at neutral position--Estopedist1 (talk) 06:32, 19 June 2024 (UTC)[reply]

Removal of ISNI by User:Epìdosis

Reporting: https://www.wikidata.org/w/index.php?title=Q37594&diff=prev&oldid=2179820220 - User:Epìdosis removed a valid ID. This breaks database-connections, e.g. via OpenRefine. It might be OK for some secondary IDs, but for ISO-IDs that are widely used this causes much more trouble. Especially since it is a fixed lenght ID with no known widely used overlap, i.e. it can be used in regular search fields to find an item (not so for the IDs by e.g. DNB/GND, NTA).

Please undo all such edits and if the user continues, block him. Friedrich Kettler (talk) 00:49, 15 June 2024 (UTC)[reply]

Hi, I see also Wikidata:Project chat#Removal of ISNI by admin, I answer there. Epìdosis 07:27, 15 June 2024 (UTC)[reply]
Doesn't look like a new user. You might want to request checkuser for a possible block-evasion. Infrastruktur (talk) 09:47, 15 June 2024 (UTC)[reply]
Probably the same as Special:Contributions/Rostworowski. Peter James (talk) 11:44, 15 June 2024 (UTC)[reply]
This is as clear as it gets, even without checkuser this is the same behaviour. Please block asap. Sjoerd de Bruin (talk) 13:54, 15 June 2024 (UTC)[reply]

Report concerning Twofivesixbot

Twofivesixbot from Mahir256 is currently making edits to replace property P7859 (P7859) with WorldCat Entities ID (P10832). But there is no consensus for this migration. Which is why I asked Mahir256 on both his talk page and the delete discussion page to suspend this task of his bot immediately. Because he allowed the deadline that I set in the deletion discussion to pass unused, I hereby demand administrative intervention. --Gymnicus (talk) 20:09, 15 June 2024 (UTC)[reply]

I am afraid you seriously misrepresent the content of User talk:Mahir256#Twofivesixbot deletes statements. Ymblanter (talk) 09:38, 16 June 2024 (UTC)[reply]
To what extent am I misrepresenting the content? --Gymnicus (talk) 13:58, 16 June 2024 (UTC)[reply]
In the discussion, two users objected to you. You are portraying it like if you gave a warning and then nothing happened. Ymblanter (talk) 17:40, 16 June 2024 (UTC)[reply]
Yes, I also issued a warning on the deletion discussion page for the property. Mahir let this warning or ultimatum pass and the Twofivesixbot is still processing it today. I also don't understand why you mention the rejections of my request by Mahir256 and Epìdosis. Because it is clear that the two advocates of migration are defending them. But this section is about whether the keep camp, to which I belong, was included in the discussion about migration or whether the delete faction is pushing for deletion indirectly and has not included the keep camp in this consideration. And since I, as a supporter of the complete retention of the property, was not once pinched in the discussion about migration and there was no new vote on migration, I consider my demand here in this section to be correct. --Gymnicus (talk) 21:02, 16 June 2024 (UTC)[reply]
What is problematic about replacing a deprecated property with the current one? --Ameisenigel (talk) 15:00, 16 June 2024 (UTC)[reply]
The problem is that, as already mentioned, there is no consensus on these edits and there was no vote on whether a migration should be carried out. A smaller group of deletion advocates have simply come up with a detour on how to delete the property, even though there is no consensus on this. And then in these considerations they didn't even include the group of people who are against the deletion of the property and to which I also belong. --Gymnicus (talk) 15:41, 16 June 2024 (UTC)[reply]
Let me get this right: You basically object to the deletion of the values for the old property, and you have no objection to the migration plan that was proposed in March this year? If you do object to the migration plan, please post a specific objection in the property deletion discussion. Infrastruktur (talk) 21:27, 17 June 2024 (UTC)[reply]
I have objections to both the deletion and the migration. And I complain that the group that wants to keep the property was not included in the planning of the migration and was not asked for its opinion. In addition, there was basically no vote on the migration idea. At least I don't see any section where I could cast my vote. For this reason, I demand that the migration be stopped until it has been properly discussed and voted on. --Gymnicus (talk) 22:00, 17 June 2024 (UTC)[reply]

Report concerning Olea

A few years ago the user @Olea: added a dataset to Wikidata about Digital Guide to the Cultural Heritage of Andalusia (Q5758805). This file, in many cases indicates elements with ambiguous terms in a table, such as house, when in reality what it is talking about in the text is more specific buildings such as a town hall. The source clearly explains that it is a town hall, the term house is very general and not very precise. Furthermore, the source itself indicates that it is a town hall, there is no doubt about it. A few days ago Olea undid here my edition, because he says that the source indicates that, but it is not really a house, nobody lives in it. I have also indicated to him that it was not relevant to put "Contemporary Age", as he has put in all the elements of Digital Guide to the Cultural Heritage of Andalusia (Q5758805), because he is already adding the specific year. It seems that he would like to add more editions because it is not important information. Another error with the source is to interpret that the years that appear in the table of links such this are really the beginning and end of the use of the building, as here has indicated. In this item I deleted the incorrect year because the source indicates it was built in 1929 and he has undone me again, even though I added the referenced year just below. All the elements he added are created like this, and after telling him it refuses to modify them correctly because he says the source says that. The problem is not exclusively this. When he added the dataset, I indicated that he had duplicated hundreds of elements, and I had to merge many of them. He told me he was working on it, but at no time has he responded to my messages about its completion and I have recently found several more, so he is not dedicating himself to solving these problems. He also duplicated property values ​​and I sent him a query with 826 duplicates that I had left there over the years. This problems are added to other datasets that he also added on other topics, use Mix'n'Match and leave the names as indicated by the tool even if they are in capital letters and without more data to identify the elements, other duplicates issues, etc. I ask that the user be told that he cannot add datasets without making prior queries, that he has to review the veracity of the source data before adding them, that he has to review the data after inserting it to erase all those errors from the tools introduce, that he cannot move on to other tasks until he has correctly left the added data and that he answers the messages that are written about it, solving the errors and not hindering the tasks of the rest of the users. Thank you. Vanbasten 23 (talk) 09:55, 17 June 2024 (UTC)[reply]

I have asked Olea to respond here — Martin (MSGJ · talk) 11:59, 17 June 2024 (UTC)[reply]
Thanks @MSGJ, but I don't think I have nothing significant to respond here :-) —Ismael Olea (talk) 18:23, 17 June 2024 (UTC)[reply]
If you have created items containing errors, then it seems reasonable to ask you to fix those up, or to provide a timescale for when this might be done. Are you willing to do this? — Martin (MSGJ · talk) 21:13, 17 June 2024 (UTC)[reply]
@MSGJ It is 2024 and I'm fixing any error I'm finding since that data load in 2020. I'm still updating when I find updates at the source. You can check my edits at 10th of June or before as an example. Other users could confirm I'm actively curating all the Andalusian heritage in Wikidata (more than 24k items) since then. Not just that, some months ago I wrote a retrospective about my experience with this data set I presented in Wikidata Days 2023. So yes, I'm willing to keep and enhance the dataset quality and integrity. —Ismael Olea (talk) 16:28, 19 June 2024 (UTC)[reply]
 Comment I think that in the two answers you have given here you do not provide clear solutions as we are asking. "I'm willing to keep and enhance the dataset quality and integrity" you said it several times, what is going to change now? You say you started in 2020. Shortly after I started writing to you about the matter. After 4 years we continue here. Do you understand the frustration of a user when he does not see solutions to problems, and also does not receive a response to his messages? I had to merge many elements and I told you that there were other problems to solve. You told me you were on it. You made other insertions, you fixed some problems that arose, and you still didn't spend any time on it. I wrote to you again, you were still at it. In June 2022 you proposed other different jobs and I told you again that you were not paying attention to these problems. I have let it be, but now I change a property and you revert it saying that it is fine, when it is not, thereby preventing others from solving your errors. You say "other users could confirm", am I not another user? What do you call "willing to keep and enhance" when you have not yet deleted all the end dates of the instances? That data has been wrong for 4 years and you keep letting it pass. The same as the query I sent you. I dedicate my time so that there are no solutions... Also, I don't think it's appropriate that you give us a link to promote the work you do outside of here, while you are not respecting the rest of the community. I think I am always available to help people, but if there is an intention to do things well. We all make mistakes, but you have to be a little sensitive with the rest. --Vanbasten 23 (talk) 20:13, 19 June 2024 (UTC)[reply]

Report concerning User:Domenico30303

Domenico30303 (talk • contribs • deleted contribs • logs • filter log • block user • block log • SUL (for IP: GUC)) — Reasons: misleading desc. changes ―Mykhal (talk) 11:03, 17 June 2024 (UTC)[reply]

Blocked — Martin (MSGJ · talk) 11:54, 17 June 2024 (UTC)[reply]

Block request

Nama24Pok (talk • contribs • deleted contribs • logs • filter log • block user • block log • SUL (for IP: GUC))

Continue this, continue en:WP:ILLEGIT and en:WP:SCRUTINY, zh.wiki blocked.--MCC214 (talk) 04:05, 18 June 2024 (UTC)[reply]

✓ Blocked indef per request. All edits reverted Estopedist1 (talk) 07:16, 18 June 2024 (UTC)[reply]
Estopedist1, also, please block all list in extended content, this user continue illegit and scrutiny eight years ago.--MCC214 (talk) 12:30, 18 June 2024 (UTC)[reply]

Report concerning User:Its the koala brotgers that im sitting with

Its the koala brotgers that im sitting with (talk • contribs • deleted contribs • logs • filter log • block user • block log • SUL (for IP: GUC)) — Reasons: Is adding IMDb ID (P345) with nonsense values. ―Premeditated (talk) 06:12, 18 June 2024 (UTC)[reply]

✓ Blocked already globally blocked Estopedist1 (talk) 07:16, 18 June 2024 (UTC)[reply]

Semi-protection for Wikidata:Username policy

Please semi-protect Wikidata:Username policy - frequent IP vandalism, page cannot be improved at all (redirect only). Jklamo (talk) 09:20, 18 June 2024 (UTC)[reply]

✓ Done for one year. --Ameisenigel (talk) 09:35, 18 June 2024 (UTC)[reply]

Report concerning 91.63.248.135

Please Block 91.63.248.135 (vandalism). Please also undo his edits --CVComposer (talk) 12:06, 18 June 2024 (UTC)[reply]

All edits reverted and globally blocked. --Wüstenspringmaus talk 12:43, 18 June 2024 (UTC)[reply]

Semi protection for Q29574353

Please protect Q29574353 from regular vandalism. Chouette bougonne (talk) 13:18, 18 June 2024 (UTC)[reply]

This does not look like vandalism to me. Ymblanter (talk) 18:59, 18 June 2024 (UTC)[reply]
✓ Protected for six months. Edit warring Estopedist1 (talk) 06:34, 19 June 2024 (UTC)[reply]

Add Romani article for the state of New York to Wikidata.

I created the article in Romani and I can’t add it to Wikidata because it’s protected.

https://rmy.wikipedia.org/wiki/New_York_(stato) 2600:6C50:7E00:20C:4934:5CFA:B9CC:146D 02:37, 19 June 2024 (UTC)[reply]

Blocked the /40 for for now. This should be handled by someone who can place a global block and handle cleanup on romani and simple wiki. Infrastruktur (talk) 04:48, 19 June 2024 (UTC)[reply]

Large edit on deletion request page has caused data loss.

https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_deletions&diff=prev&oldid=2183461779

This edit seems to have removed a large number of requests, including ones I have made. I'm assuming some kind of edit conflict was ignored. Can an admin review it and recover the lost requests and discussions? William Graham (talk) 06:20, 19 June 2024 (UTC)[reply]

✓ Done Thanks for bringing this up! --Ameisenigel (talk) 09:21, 19 June 2024 (UTC)[reply]

Protection request for Q213518

Please semi-protect Q213518. Reason: Persistent vandalism XReport ----Wüstenspringmaus talk 10:57, 19 June 2024 (UTC) [reply]

Undelete Kaiman Lee wikidata entry

Please undelete the entry for Kaiman Lee on wikidata (Q126734059). More editing needs to be done. Ninakp (talk) 21:15, 19 June 2024 (UTC)[reply]

 Question Have you consulted the notability policy? If yes, could you elaborate a bit how you believe it meets the notability requirements? --KonstantinaG07 (talk) 22:15, 19 June 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Administrators%27_noticeboard&oldid=2184022953"