action=purge?

This is part of https://www.wikidata.org/wiki/Help_talk:Property_constraints_portal#Improvements_for_2018 . Would start with just binary in the first version and maybe do a second version that looks for real references (and not imported from).

@Shonagon please don't comment on old closed bugs with new comments. Please open a new bug. I did this for you at T194956

Confirmed on both Wikidata and the Dutch Wikipedia using Firefox.

I emailed Freenode. We should poke them if we haven't gotten confirmation by Thursday.

Note: Because we were a bit late with deploying this change, it didn't actually work and we hit the limit. @Reedy what was the limit again and where is this documented? I would like to update https://meta.wikimedia.org/wiki/Mass_account_creation#Requesting_temporary_lift_of_IP_cap to prevent other people from running into the same problem.

@Urbanecm with these kind of things I usually take it a bit broader. Feel free to enter what you think is a good number, but I would just do 250. I updated the task with the ip range based on the ipaddresses I got from @jcreus

I cloned Pywikibot using $ git clone --recursive ssh://multichill@gerrit.wikimedia.org:29418/pywikibot/core.git pywikibot

And https://www.wikidata.org/w/index.php?search=haswbstatement%3AP217%3DSK-C-5 works :-). https://www.wikidata.org/w/index.php?search="SK-C-5" doesn't work (yet?). Is that the next step?

I'm sorting out the hackathon 2018 board (on which this task is) and well described tasks generally have a higher chance of actually being worked on. Might not be the best board for a tracker task.

What is the goal of this task? Can you elaborate?

I'm pretty sure this is done. Please re-open if that's not the case

In T163642#4192776, @Smalyshev wrote:

@Lea_Lacroix_WMDE Also, for newly edited items it should be working as soon as wmf.3 is deployed. But for older items it will need reindex.

@Lydia_Pintscher @Ladsgroup any status update on this?

In T192690#4153593, @Legoktm wrote:

https://gerrit.wikimedia.org/r/#/c/427156/

This seems inherently broken, the noratelimit right exists for a reason. I'm not really sure how to work around this in MassMessage besides disabling rate limits I suppose?

Did I miss an announcement to wikitech-l/wikidata-tech that something like this was going to happen?

For me the image is a link to https://commons.wikimedia.org/wiki/File:Douglas_adams_portrait_cropped.jpg and the link goes to the local page. No mediaviewer. Linking directly to Commons is something that most Wikipedia's have been doing for years to eliminate the extra local step.

I don't agree on renaming, that would break it for the users who use it. It's just a bunch of symlinks to /data/project/pywikibot/ anyway. What I would propose:

• Change owner to tools.pywikibot for /shared/pywikipedia/ (now a big mix)
• Link /shared/pywikibot to /data/project/pywikibot/public_html/core/
• Leave a readme in /shared/pywikipedia/ to say it's deprecated and people should use /shared/pywikibot/

In T184948#4145885, @Sjoerddebruin wrote:

Seems like this is affecting the MassMessage extension: https://www.wikidata.org/w/index.php?title=Special:Log/massmessage&offset=&limit=250&type=massmessage&user=

I don't like this "solution" at all, this is more like a work around to prevent more incidents instead of solving the real problem. Re-opening because:

• I don't see a link to where the documentation is updated on Wikidata. Probably https://www.wikidata.org/wiki/Wikidata:Bots should be updated
• How do I test this in a sandbox way to figure out my code handles this properly. For replag I can send a dummy value, but how do I do this here?
• Third and most important: This is not a real solution, but a work around.

As in T154771 , we should wait a while before actually dropping it. Somewhere in the range 9-12 months is reasonable. Putting the task on stalled in the meantime.

Viaf part is probably covered by T99899

In T99899#4121954, @Smalyshev wrote:

make the index assume the entries are distinct and unique, so when it encounters a second Wikidata item with the same external ID, it just overwrites it

Index can't do that unfortunately. I don't even think there's such thing as unique field in ElasticSearch - the only field that is unique is the document ID.

So if you have two items with the same external ID, the search will find them both. Now if you build some service on top of it (like special page) it can interpret the search results and resolve the collision. But I see no way to not have duplicates in the search index if they are in the data.

Currently we have 2614 properties of type ExternalId of these properties 2260 properties have both the single and distinct constraint ( https://query.wikidata.org/sparql?query=SELECT%20%3Fproperty%20%7B%20%3Fproperty%20wikibase%3ApropertyType%20wikibase%3AExternalId%20.%20%3Fproperty%20wdt%3AP2302%20wd%3AQ19474404%20.%20%3Fproperty%20wdt%3AP2302%20wd%3AQ21502410%20%7D ). You could make a list, but that sounds like a maintenance burden.

In T191114#4109676, @debt wrote:

Hi @Multichill - this is a very interesting idea, but it goes against all of our privacy concerns with the Wikipedia community and the movement in general. I believe that this idea has come up several times over the years, but because of privacy concerns, nothing has been done with it (marking as declined).

In T35704#4105584, @LGoto wrote:

Closed as part of board grooming process.

In T184948#4089557, @Magnus wrote:

So,

• either WMF expose the "overload status" so we can throttle on demand,
• or WMF delay the API response accordingly, so we don't have to do anything,
• or WMF scale to demand :-)

Hi Magnus,

In T184948#4079500, @Magnus wrote:

I have added a 5 second delay after item creations. I also added a mechanism to have a delay after any other edit type.

Note that this limits single threads only. QuickStatements, various SourceMD webtools and bots, Mix'n'match sync etc. can still add up. Also, this does not effect my JavaScript tools on Wikidata proper.

Edit: Rate limiter diff

In T190516#4079973, @Anvilaquarius wrote:

I'd be grateful if people could please think about the community before requesting cosmetic stuff that results in important tools to be deleted.

By the way, I'd rather have all the crappy Wikimedia Map service map graphics removed and have every tool including loading OSM graphics.

In T184948#4078538, @Lydia_Pintscher wrote:

There are other tools that are going too fast like fatameh as well. This isn't something we should have to correct on a tool-by-tool basis.

In T184948#4075653, @Ladsgroup wrote:

In T184948#4059447, @Multichill wrote:

In T184948#4052662, @Ladsgroup wrote:

I personally would like to strip the right from the bots and enforce a rate limit for them as they just don't care about what we say.

If bots ignore replag ( https://meta.wikimedia.org/wiki/Bot_policy#Edit_throttle_and_peak_hours ) these bots should just be stripped of the botflag. The good shouldn't suffer because of a small number of problematic users.

Too many edits in too small amount of time can affect infra in several ways, one is replag, one is dispatch lag, one is jobqueue size. If edit is about creating new items it can also affect the infra in some other ways too as we want to be consistent about Q-ids and do not assign same Q-ids to two items.

Overall, if community stick to a rule of thumb like *max* 60 edits / min. and *max* 10 new items/min. and community actually enforces that (and don't wait until the whole infra falls down and we ping them so they stop), there wouldn't be a need to have such ticket in here in the first place but this continues to happen all the time.

Interesting 145.97.39.140 is a Kennisnet IP that was used by the Wikimedia server vandale (see https://meta.wikimedia.org/wiki/Wikimedia_servers_listed ). I wonder how that got blocked....

In T184948#4052662, @Ladsgroup wrote:

I personally would like to strip the right from the bots and enforce a rate limit for them as they just don't care about what we say.

In T172659#4054233, @TheDJ wrote:

In T172659#4053782, @Akoopal wrote:

It had. The default google api included a search box with the map widget.

I just checked the old code to make sure, It positively didn't. I think you are confused with https://tools.wmflabs.org/coord/

You should start by publishing your source code. I asked this before multiple times at https://www.wikidata.org/wiki/User_talk:Ivan_A._Krestinin#Publish_the_source_of_KRBot_please . That way people can help to improve your code etc. According to the Wikimedia Cloud/Toolforge rules you're not allowed to run non open source code anyway (https://wikitech.wikimedia.org/wiki/Wikitech:Labs_Terms_of_use).

In T145712#4037638, @Smalyshev wrote:

Yes, if there's an RC record and revision number increase, it will reload.

In T145712#4029085, @Smalyshev wrote:

So the data is not up to data in wikidata properties tables. Not sure why and how this can be fixed. Editing the item seems to fix it, so maybe there should be some bot that null-edits such items periodically?

Of interest: T89597 T89599 and T89600

Done by @Jarekt , see https://commons.wikimedia.org/wiki/Template_talk:Institution

@scfc do your thing :-)

Closing this one. AFAIK Nothing left to be done.

That explains why I keep getting these weird notifications for https://www.wikidata.org/wiki/Special:CentralAuth/NoclaimsBot . It's only configured to work on the wiki's listed at https://www.wikidata.org/wiki/User:NoclaimsBot#Overview

Thanks for implementing this. What's left is updating https://www.wikidata.org/wiki/Module:Property_documentation to make use of the deprecated rank. Left a message about that on https://www.wikidata.org/wiki/Template_talk:Property_documentation#Handle_property_constraint_with_rank_deprecated