@Smalyshev / @debt :I think this is one of those tasks where we have a bit of a misunderstanding about scope (see https://lists.wikimedia.org/pipermail/wikidata/2018-August/012282.html ). Close this one as resolved and make clearly scoped follow up tasks to untangle this? :-)

I don't think anything else is using it. I would check two weeks of logs to see if anything tried to use it and if not, just kill it.

Yup, had this too. In https://commons.wikimedia.org/w/index.php?title=Campaign%3Apainting-pd-art-self&type=revision&diff=312102316&oldid=312090259 I fixed the license. This change didn't have any effect. I kept getting a broken message, see for example https://commons.wikimedia.org/wiki/File:Jos%C3%A9_Garcia_Ramos_-_El_ni%C3%B1o_del_viol%C3%ADn.jpg where it still uses the old template. Later I did https://commons.wikimedia.org/w/index.php?title=Campaign%3Apainting-pd-art-self&type=revision&diff=312135588&oldid=312102316 and that solved it almost instantly.

In T102533#4422722, @Liuxinyu970226 wrote:

For Norwegian, I strongly encourage @Multichill and other Dutch users to cease "one Norwegian" glitch, rather we, just all Wikimedians around the world, should always separate them as one of
<knip>

In T194950#4420642, @Addshore wrote:

There are still some bots and tools that are not setting appropriate maxlag values for their requests but we can follow up elsewhere with that.

In T199379#4419930, @Addshore wrote:

Should be fixed now, but pages that are already showing bad stuff will need a purge!

I ran into this because I imported data with was tagged as "NOR" and is a valid ISO 639-2 language code that maps to the ISO 639-1 "no" language code, see https://en.wikipedia.org/wiki/Norwegian_language . Norwegian is a valid macro language, see https://en.wikipedia.org/wiki/ISO_639_macrolanguage and wouldn't be the first macro language to include, we also have ar (Arabic) or ne (Nepali) as valid language codes.

In T199146#4409514, @Smalyshev wrote:

Yeah looks like ipblocks table for wikidata has block on 2620:0:862:101:0:0:0:0/96 by user "Merlissimo" with comment 'Toolserver Range - no anon edits' but this doesn't seem to match wdq9. So probably not this one.

Looks like @Dalba introduced it in https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/440096/

Thanks for fixing this guys. As an afterburner I found in T173293 that the API does filter by namespace, but isn't really supposed to do that. See example ...........

@Xqt : Why are you deprecating perfectly valid generators?

In T194950#4322078, @Magnus wrote:

Excellent, that means my existing code should Just Work (tm).

Is the "lag" value in the API reply in seconds? maxlag does not appear to be documented for the query action...

In T192800#4273584, @LJ wrote:

@Smalyshev I think we couldn't agree on implementation details, so this is probably going to be discussed at the Berlin workshop, at which time someone will add a more detailed example & description.

So I stopped operating the bot back in 2015 because the time it would cost to fix it didn't add up with the (negative) feedback.
If there are multiple people who are willing to help out here I'm more than happy to invest a bit of time to set the thing up again.

tools.heritage@tools-bastion-02:~/logs$ date
zo jun 10 11:44:09 UTC 2018
tools.heritage@tools-bastion-02:~/logs$ ls -alt update_monuments.log
-rw-rw---- 1 tools.heritage tools.heritage 96412359 jun 10 11:44 update_monuments.log
tools.heritage@tools-bastion-02:~/logs$ grep mysqldump update_monuments.log
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table monuments_am_(hy) at row: 13534
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table monuments_be-vlg_(fr) at row: 19365
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table monuments_be-vlg_(fr) at row: 56932

In T163642#4237402, @Smalyshev wrote:

@Multichill I think the point of this task were to index the statements, which is done. For searching, you can use haswbstatement for now. I am not sure whether it makes sense to copy the statement value into all field, where it would be then searchable by plain search too - may be useful for distinctive IDs but I am not sure how many of them are distinctive... I think it's better to make a separate task for this.

Freenode implemented the iline. I didn't hear anyone complain about irc so I guess it worked.

@Smalyshev https://www.wikidata.org/w/index.php?search=%22SK-C-5%22 doesn't work yet, but this task has been closed. Can you explain? This is listed in the task description as something that should work.

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.