- User Since
- Oct 13 2014, 7:06 PM (451 w, 5 d)
- IRC Nick
- LDAP User
- MediaWiki User
- -jem- [ Global Accounts ]
Aug 26 2022
@Dzahn, thanks, I assume that your changes are the best solution that doesn't involve deeper changes that would be of greater magnitude than the problem to be solved. Bot operators as me can just check the update times in Wikistats for each project family and adapt their running times, and Wikistats operators (currently that would be you) can try to add new projects near but before 21 h UTC (but it wouldn't be a big deal if not). Just one detail: you approached all Wikimedia families to 0 h UTC, except for Wikiversities...
Aug 24 2022
Thanks! Just another suggestion: I understand in the code that the job is run at 05:39 UTC; could it be moved to around 23:45 UTC (or sooner, if it takes more than 15 minutes to complete) so that the Wikistats midnight update gets the data as fresh as possible, specially for new projects created in that day? (Well, another option could be to move the Wikistats update, if @Dzahn agrees...).
Aug 22 2022
This issue happened again with the most recent Wikipedia, pcmwiki (I haven't checked other recent sister projects). @Dzahn has run the script manually again (thanks!).
Aug 12 2022
Nov 18 2021
Nov 17 2021
Dec 20 2020
Added madwiki as 315th Wikipedia and skrwiki as 316th Wikipedia:
Nov 3 2020
Aug 17 2020
Added as 313rd Wikipedia:
Aug 3 2020
Notified in eswiki, I can replicate it and it happens in the mobile versions of all pages of all Wikimedia projects.
Aug 1 2020
Added as 312nd Wikipedia:
Jul 26 2020
Added as 311st Wikipedia:
Jun 2 2020
Thanks for your complete explanation, @jcrespo. If I have understood, edits previous to a page move can't be tracked with recentchanges even if they are "recent" and viewable in the history, so I will have to fix accordingly my statistics bot for edit-a-thons... this had never come up after several years (I guess nobody moved sandboxes to the main namespace, or nobody noticed the problem and warned about it), so I thought in a bug and they didn't "stopped me" in irc; sorry about that.
Jun 1 2020
May 11 2020
I'm very sorry for this. I fixed it some weeks ago. I will add automatic checks to prevent this from happening again.
May 2 2020
May 25 2018
Working again. Thanks, @Anomie
May 24 2018
Mar 7 2018
Feb 4 2018
@MarcoAurelio, I have to correct you; the bot is using the damaging/goodfaith model since it was set up, which is also the only possibility left, as the reverted model was disabled at the same time. The general impression is that under the new model we have more false positives, which is very unexpected.
Dec 9 2017
I'm sorry for the inconveniences and for the late answer, I was delayed with the mail. I don't know if my code is to blame, I haven't made any recent changes, but I'll pay more attention in the future. Also, if needed, you can reach me much faster as jem in IRC; I have permanent connection. Thanks for the intervention.
Nov 28 2017
Please note that some Wikipedias have very restrictive policies about navboxes (eswiki doesn't allow more than three lines and those which don't offer more than categories), so the consumption argument wouldn't apply. For current mobile and app users this lack of information is not a minor bug.
Oct 14 2017
After removing the <noinclude> tags, this is fixed, as stated here. Thanks everyone. And I give due credit to @Bikendi1991, who originally reported this in the #wikimedia-ayuda IRC channel.
Oct 12 2017
This task seems valid and useful; I can understand that it is declined with an explanation, but IMHO marking as invalid is not the right way to close it.
Aug 17 2017
@dbarratt , as I said, I have done just tests, and I'm not aware of article_first_contributor being used in any filter, so I have no examples; but after your previous comment of the "lazy load", I think that maybe it works "in production" even if it doesn't in the tests (which should be fixed anyway, or documented, at least), so I want to add it to a filter and check its log afterwards, but I have been busy these days. It's no problem if you want to try it yourself :), I'll do it in a few days, I hope.
Aug 9 2017
+1; I could think they appear in creation order of the permission, but "confirmed user" is almost bottom. Alphabetical order could also help to realize the current names used and to possibly improve translations of the new (or not so new) ones.
Aug 7 2017
@dbarratt , I've tried and the results are as expected: user_name has always correct data, so, as it can't never be an empty string, when I test
article_first_contributor == user_name
the result is always false. And I've also discovered that, when I use the "Test a filter against previous edits" page, article_first_contributor does have always the correct value, but I'm using the "Examine individual changes" page from any log entry, and the value is always empty there (but other variables, including user_name, have the correct values).
Aug 5 2017
@dbarratt I didn't get a fail. I wanted to include article_first_contributor in an existing filter (to let the article creator remove his/her text), and when I began doing tests with it, as explained, I found the problem, so I didn't move on, as it was obvious it wasn't going to work "in production".
@dbarratt: The issue is still there. No need for test usernames; I just use the "examine" interface for any abusefilter log entry, and from any test code that matches the change, if I add
& article_first_contributor == ""
the test remains positive, but with the correct or any other value inside the "", the test doesn't match. I've checked again a few minutes ago.
Jul 23 2017
May 15 2017
I have found six eswiki deleted articles which still appear in the page table in Labs, located by using this trial-and-error query after one of them was detected in my Labs tool:
Mar 8 2017
Feb 21 2017
Thanks, @Jhernandez. To give proper credits, the bug was first reported by eswiki user Bikendi1991 in the #wikimedia-ayuda IRC channel; then I reproduced it and searched for help :)
Dec 23 2016
Hi, Urbanecm, and thanks for the quick answer. Sorry, I had understood that the svg locations where somehow "standard"/"automatic" in Commons; maybe I just saw too few of them. Our svg is located at https://commons.wikimedia.org/wiki/File:Wikipedia-logo-v2-es.svg. If there's something else that we should do, I'll be watching this task.
There has been recent interest in eswiki about getting the same high resolution improvement that enwiki has (initially it was about using plain svg, but I understand conversion to png is intentionally preferred because of compatibility). Checking for it, I have arrived here... and now I see that eswiki is probably the biggest wiki that is still out of this. I wonder if this task will move on soon, as trying a local patch in Common.css doesn't seem a good idea. I think priority shouldn't be low, as screens with higher resolutions are getting more common with time... and I guess that in the near future this high-res png files will be the default ones, with no extra config need; but if that isn't coming soon, I would rather have the eswiki addition, at least :)
Nov 27 2016
Aug 10 2016
@Ladsgroup: Probably because I used the first URL I found when searching, and since then until now I hadn't realized that was a better choice. I have changed my code. And thanks anyone; I confirm that the problem hasn't happened again.
Aug 2 2016
The problem has been happening for several days now, and it can last a few minutes or a few hours. As my patroller bot make continous use of the ORES API, this is quite a problem for me. Thanks in advance.
Jul 12 2016
Jun 6 2016
Checked and working, thanks! And sorry for the Debian package vs. LaTeX package confusion, I should have explained better.
Apr 20 2016
Dec 15 2015
Sep 22 2015
@kaldari, yes, I already stated that there is no easy way. It is possible to join the recentchanges and user_groups tables to obtain the most active accounts with the bot flag (the unflagged bot accounts will usually be editing at a "human" rate and, as such, much less active), but to get the operators it would be needed to check the user page of the bot and search for a parameter of a bot-identifying-template, or something like that, very project-depending anyway. In eswiki we solved the problem by creating https://es.wikipedia.org/wiki/Template:Controlador, which returns the operator and also allows us to identify the unflagged bot accounts, but of course it must be updated by hand. For just 10 projects, as in this case, for sure it is faster to ask a trusty user from each one for a list of active bot operators, and that's why I offered for that; but, of course, I don't want to delay any schedule. I'll be glad if I can help and also if it isn't needed or there's no time for it.
After https://es.wikipedia.org/wiki/Wikipedia:Caf%C3%A9/Archivo/T%C3%A9cnica/Actual#Detector_de_desambiguaciones = https://es.wikipedia.org?diff=85143039 was opened, @Superzerocool has fixed it completely for eswiki (thanks!), and currently it also seems to be working in glwiki, at least for @Elisardojm's example and also in all of my tries. I wait for him to confirm that and close this as solved.
Sep 20 2015
Maybe I'm late for this, but I think that for reaching people with "technical opinions", you should add the operators of the most active bots in those projects; programming is also an important technical work which leaves less time for editing, even in "tech namespaces". Yes, I'm an example of that, and I don't appear in P2064; and yes, it won't be so easy to extract that list of operators. If you consider adding them by hand, I can give you a list for eswiki gladly.
Sep 18 2015
I also have participated and confirm my interest in this possibility (which I think should be the default)
Sep 6 2015
Aug 27 2015
Aug 19 2015
MZMcBride: Yes, sorry, I should have provided a link in the description. Aklapper: I agree, and of course, if some Wikimedia-user-preferences could be read and used, that would be better. But anyway, I think geolocalization could be useful as last option; some other major web sites do it (or they seem to).
Aug 14 2015
This seems quite easy to do, considering its benefits. Also, I'm aware of abian's (good) work in his script, so this is a blocker for real improvements and results in GLAM projects. I hope it can be solved soon.
Aug 9 2015
Thanks., Dzahn. I have checked and I do have ssh access to both instances listed in wikitech. I wait for the instructions now, as I see I have no permissions for mysql, so I guess there are tools to know/configuration to do/etc. I leave the task open for now and we'll keep in contact.
Jul 30 2015
It could be interesting that the landing page showed more information about tools with a similar name or Labs projects with the same name.
Jul 19 2015
May 13 2015
I think I have solved this now. There were two problems with the "_p" at the end of the database names, I guess because of the change from the toolserver to the toollabs metadata, and also a check of existence was needed before processing results from each wiki, I guess because of a change of behaviour among PHP versions. Anyway, please check, and sorry for the delay in taking on this; I promised to have a look when I was added as maintainer of this tool, so better late than never...
Jan 28 2015
Dec 26 2014
I think editintro/preload would be very useful not just for new users, but for many kinds of repetitive administration tasks/queries for which preloads are now used. Having TemplateData integrated (I guess), users could be presented the fields they have to fill in the visual way, avoiding errors and fully controlling the input.