Approve icon.svg
Unblock request granted

This blocked user asked to be unblocked, and one or more administrators has reviewed and granted this request.

block logipblocklistcrossblockluxo'sunblockremove gblock • contribs: +/-

Request reason:
ip range block exempt, I need to use this user for the bot, through Digital Ocean server which is blocked
Unblock reason:
Uziel302, I have added the IP block exempt user group to the bot. Esteban16 (talk) 16:05, 22 November 2019 (UTC)

This template should be archived normally.

беларуская (тарашкевіца)‎ | bosanski | čeština | English | español | français | Plattdüütsch | Nederlands | português |


Source code?Edit

Hi, could you please share the source code for this bot?--So9q (talk) 09:38, 28 November 2019 (UTC)

User:So9q, see Wikidata:Requests for permissions/Bot/Uzielbot. Uziel302 (talk) 09:53, 28 November 2019 (UTC)
Thanks!--So9q (talk) 10:36, 29 November 2019 (UTC)

Maxlag parameterEdit

Hey Uziel302, this bot does not seem to have a maxlag throttle which pauses its activity during times of high server load. Per Wikidata:Bots, "bots should respect maxlag", meaning that automated editing should be paused when the maxlag parameter is higher than 5. Can you please implement this in your bot code before you continue editing? In case of questions, feel free to ask. Thank you, —MisterSynergy (talk) 21:08, 11 March 2020 (UTC)

MisterSynergy, thanks for letting me know, I added it to the code, but I keep getting responses of around 7 secs lag, should I wait for another time? How can one tell when it is a good time to run the bot? Uziel302 (talk) 21:39, 11 March 2020 (UTC)
You can track the maxlag over time at this Grafana dashboard ("Max Lag" panel). As you can see, there is a zigzag-pattern with values between roughly 1 and 10, and this is unfortunately pretty common these days. Your bot may edit as long as the value is 5 or smaller, and start/stop operation based on the actual maxlag value; it can retrieve the maxlag value from the MediaWiki API, and as far as I am aware, it should be doing so not more than once per minute. —MisterSynergy (talk) 21:50, 11 March 2020 (UTC)
MisterSynergy, would you elaborate on that one minute limit? I added maxlag:5 to the api calls, so everytime the script sends edit it includes the maxlag param, is there a better implementation?Uziel302 (talk) 21:53, 11 March 2020 (UTC)
Sorry, yes you are correct, using the maxlag parameter in each request and evaluating the server response is better. I was just writing an update for my previous comment when I got an edit conflict with your comment… :-)
I do not do much interaction with the API directly, I just use the pywikibot framework which handles all of this for me. I was a bit confused from something else related maxlag which I did recently. —MisterSynergy (talk) 21:58, 11 March 2020 (UTC)

Hey Uziel302, whatever you did yesterday to the configuration does not have effect the bot's behavior today. It still hammers 70 edits per minute while the servers operate at the limit. I blocked the bot, but will unblock of course as soon as you confirm that the maxlag throttle works as desired. —MisterSynergy (talk) 10:42, 12 March 2020 (UTC)

MisterSynergy, my bad, I raised the maxlag, it is now back to 5.Uziel302 (talk) 10:46, 12 March 2020 (UTC)
Please don't do this. The servers are operating at their limits pretty often these days, and this is clearly an unpleasant situation for all bot operators. I will unblock the bot, but continue to watch its behavior (as I do for all other users). —MisterSynergy (talk) 10:49, 12 March 2020 (UTC)
MisterSynergy, sorry for the mess, thank you for unblocking and watching the bots in general. Is there a way to make the bot just wait until maxlag is back to 5, I currently need to manually edit the script to the point it was stopped.Uziel302 (talk) 10:54, 12 March 2020 (UTC)
Well, it depends on the framework that you are using. I only know pywikibot, which automatically pauses editing when maxlag>5 and restarts as soon as maxlag is fine again.
Following mw:Manual:Maxlag parameter, the bot may re-try editing every five seconds if the edit was not saved due to high maxlag values. If you use a self-made bot framework, I guess you can try to edit in a "while True:" loop and break out of it once the edit was successful. You should be able to evaluate whether the edit was successful based on the API resonse headers as stated on the page linked before. —MisterSynergy (talk) 11:04, 12 March 2020 (UTC)

MisterSynergy, maxlag got to 10, how do I check who is responsible for it? Uziel302 (talk) 18:06, 21 March 2020 (UTC)

There is usually not a single user responsible for high maxlag values. The problem these days is that the Wikidata server infrastructure has a significant bottleneck that is not able to cope with the overall edit load. The bottleneck is well-known, but bot well understood and thus not yet removed. There is nothing you can do about it. —MisterSynergy (talk) 18:52, 21 March 2020 (UTC)


Hi, please merge to the earlier lexeme. Your bot seems to do systematically the opposite. --- Jura 00:14, 28 March 2020 (UTC)

  • Can you repair them? --- Jura 00:16, 28 March 2020 (UTC)
Jura, I didn't know of such rule, most of the merges I did are of lexemes that I uploaded, so there wasn't any difference between the slightly older lexeme, just had some issues with the bot and it caused duplicates. I know some of the lexemes are older and were created by others, I may be able to find them but I'm not sure how important it is. Do you have any reference?Uziel302 (talk) 00:49, 28 March 2020 (UTC)
Reference for? --- Jura 00:58, 28 March 2020 (UTC)
Jura, for the importance of the direction of merge. I understand why if one item has long history and one is newly created that it is better to merge the new to the old but in case of few edits on both items, why does it matter what redirects to what?Uziel302 (talk) 01:01, 28 March 2020 (UTC)
It's explained at Help:Merge#Select_recipient_item. Otherwise our entities would keep changing ids. --- Jura 01:06, 28 March 2020 (UTC)
The rule is about usage and age is only a suggestion when in doubt. In my case most items had close to zero usage and the age difference is little, so I will leave it as is. If you have specific items that should be switched based on usage, let me know.Uziel302 (talk) 07:07, 28 March 2020 (UTC)
I switch "urbs" that was in use. Please fix the ones where the id is lower then the ones you created yourself.
However, the rule is to keep the existing id (not to create new entities and then redirect existing entities there).
It's an exception that much used entities are kept even if there is a lower id, e.g. when there items with labels in rare languages and no statements that only get identified much later. For lexemes, this should rarely be true.
Please repair the ones you merge and ensure your bot functions correctly going forward. You can't create duplicates and then merge other users contributions in it --- Jura 09:09, 28 March 2020 (UTC)
Jura, I just reverted redirections of all the old lexemes.Uziel302 (talk) 10:59, 28 March 2020 (UTC)
Good. BTW, quite an impressive increase in coverage over the last days for Latin [1]. thanks for that! --- Jura 11:35, 28 March 2020 (UTC)