Hi, indeed there are a few discussion/talk pages in our Wikipedia: namespace, particularly the ones of our local Village pump (Café), but we think it is a minor issue that we can assume, compared to the advantages of the change; perhaps we could add a warning at the top of those pages recommending to swap to the code editor in order to edit them, or any other similar idea that you suggest...

I have completed the migration by using external servers when needed, and I'm already running Kubernetes in my webservice, although it seems the grid-deprecation tool is not aware (?). Thanks again, I'm closing this task as resolved.

Yes, I was told about that possibility in IRC, but if I remember well, it would require using Gitlab for the code and a deep change in my work dynamics, which I can't afford currently... I have my own code for source publishing and connections with code in external servers, and I prefer not to change things while they are working, or to change them as little as possible. Anyway, thanks again; I hope I can get through this and report by the end of this week.

Hi, @dcaro, thanks for your interest. I'm afraid things got complicated; I asked in the IRC channel for guidance in December and I still have to find time to figure things out in the next days. Basically, one of my tools under jembot uses ssh and pdflatex calls under php to generate dynamic png files, and those calls/binaries aren't available in the kubernetes environment, so probably I will have to do that task elsewhere/elsehow. Recently, I have completed the Spellcheck migration (T320053), which was more urgent. I will report as soon as possible. Thanks again...

Sorry for the silence... this migration is completed; the only needed change involved the daily crontab execution which updates the wrong words lists, which I have already addressed. So, I close this task as Resolved.

I'm testing the migration now, some things need fixing but I think I can handle it; let's hope things keep going well and I'll report again (and maybe close the task) tomorrow. Thanks to @taavi and @bd808 for the help in IRC.

@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...

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

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!).

Added madwiki as 315th Wikipedia and skrwiki as 316th Wikipedia:

Added as 313rd Wikipedia:

Notified in eswiki, I can replicate it and it happens in the mobile versions of all pages of all Wikimedia projects.

Added as 312nd Wikipedia:

Added as 311st Wikipedia:

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.

I'm very sorry for this. I fixed it some weeks ago. I will add automatic checks to prevent this from happening again.

Working again. Thanks, @Anomie

@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.

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.

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.

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.

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.

@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.

+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.

@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).

@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.

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:

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

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

@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.

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.

Checked and working, thanks! And sorry for the Debian package vs. LaTeX package confusion, I should have explained better.

@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.

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.

I also have participated and confirm my interest in this possibility (which I think should be the default)

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

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.

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.

It could be interesting that the landing page showed more information about tools with a similar name or Labs projects with the same name.

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...

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.