Unblock request granted

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

Uzielbot
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)Reply


This template should be archived normally.

Source code? edit

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

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

Maxlag parameter edit

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)Reply

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)Reply
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)Reply
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)Reply
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)Reply

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)Reply

MisterSynergy, my bad, I raised the maxlag, it is now back to 5.Uziel302 (talk) 10:46, 12 March 2020 (UTC)Reply
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)Reply
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)Reply
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)Reply

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

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)Reply

Merges edit

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

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)Reply
Reference for? --- Jura 00:58, 28 March 2020 (UTC)Reply
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)Reply
It's explained at Help:Merge#Select_recipient_item. Otherwise our entities would keep changing ids. --- Jura 01:06, 28 March 2020 (UTC)Reply
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)Reply
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)Reply
Jura, I just reverted redirections of all the old lexemes.Uziel302 (talk) 10:59, 28 March 2020 (UTC)Reply
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)Reply

Why aren't you including senses in lexemes? edit

I looked at lexemes that you created פרק/פָּרַק (L217356), פירק/פֵּרֵק (L216846), and כתב/כָּתַב (L212243) and I am wondering why you are not including senses in any of them? Without the senses, it's not easy to understand what the meaning of the word is and to be able to link them to senses of lexemes in other languages. UWashPrincipalCataloger (talk) 06:34, 22 November 2022 (UTC)Reply

UWashPrincipalCataloger, I based on Hspell, imported here all the morphological analysis of Hebrew words which is non copyrightable data. Senses are copyrightable, so it can't be copied easily from other source, and should be manually added by users who are willing to write the definitions under CC0 license (meaning, keeping no rights to themselves). I added senses to few thousands but don't have time to add to all. Uziel302 (talk) 06:40, 22 November 2022 (UTC)Reply
Thanks for the explanation. UWashPrincipalCataloger (talk) 07:12, 22 November 2022 (UTC)Reply