The more I learn about this project, the less I want to adopt it. 🫣

not sure I’ll be able to get to it this weekend

it would seem reasonable to track it as a separate thing

@LucasWerkmeister : I still hesitate to complete the adoption, as most parts of the bots still run smoothly as of today and would immediately stop once you delete the confidential data, putting pressure on me to get FNBot2 up and running asap. But as the list of small bugs and new feature requests is growing: Would it be possible to share the code (without the confidental data) with me prior to the adoption, so I can have a look already and prepare the necessary changes before the actual adoption? (I'm aware that large parts are visible already, but some folders like /mnt/nfs/labstore-secondary-tools-project/request/FNBot/review_bot/ are completely hidden)

Possible alternative approach:

Pinging @M-J (to keep you in the loop on the planned changes)

I don't know why I didn't mention this when I subscribed to this task a couple of month ago, but now that it popped up again: I implemented a reminder bot for exactly this purpose in dewiki three years ago already[1], and we're currently discussing a rollout to other languages.[2]

Fixed.

Fixed in production.

Fixed in production.

For such a small chart, it would probably be best to have a cached static / non-interactive preview picture instead of rendering the full interactive chart live. This could possibly also be useful for T394262 (Treat Charts as media with previews, not as pages, in Commons category pages), which is currently more or less blocked due to the performance concerns related to rendering dozens or even hundreds of charts simultaneously. If we had a cached thumbnail picture of every chart for galleries and categories, accessible via parameter (like "mini"), this could reduce both rendering time and client side script executions:

I also like the toolbox idea, but would additionally recommend to include all charts and tabular data files used in a given article in the respective info page (e.g. https://en.wikipedia.org/w/index.php?title=Ammonia&action=info ), where we already list Templates, Modules and Wikidata items used in the article. (Thanks to @Kallichore for bringing up this idea in https://de.wikipedia.org/wiki/Hilfe_Diskussion:Chart#Seiteninformationen )

Allowing smaller sizes (not necessarily arbitrary, custom sizes - a fixed "thumbnail / preview" size with the option to expand it to fullscreen would be enough) would not only help with infoboxes or the example mentioned above, but also in cases where the chart is not meant to be studied in detail, but only included for illustrative purposes, like most charts in https://de.wikipedia.org/wiki/Stochastische_Analysis : Replacing those with the new charts in fullscreen mode would drastically reduce the readability of the article.

You can set format to auto to correct this

Doing this in the Ammonia production chart only adds a thousand separator to the numbers, making the overlap worse than before.

The axis title on the y-axis is also optional

Thanks! Didn't try this before, but yes, leaving it out completely is the best solution/workaround for the specific case of the Ammonia production chart.

I also stumbled across this problem today. Do you still plan to restore the old values? And (more out of curiosity): Why do I still see one entry from 2024 in this list when everything was overwritten in February? (Hm. This article was moved on the day of the migration. A race condition maybe?)

Perfect - thanks! (And also thanks for reviewing the open changes in the development branch and bringing them to production!)

Sorry for necro-posting, but I don't want to open a new task for this quick adoption-related question: I also requested access to https://gitlab.wikimedia.org/toolforge-repos/wosretbot a couple of days ago. Am I even supposed to get access to this repository as per the adoption policy? (Would be a convenient alternative to creating a duplicate "wosretbot2" repo) And if yes: Is anyone actively monitoring these requests in Gitlab, or should I use another channel to request access?

Thanks for following up on this, and I agree with creating a new bot for this as well. But as I just adopted another tool yesterday (T392781) which I'm analysing / repairing right now, I'd rather have this adoption being postponed for another couple of days until WosresBot works smoothly again so I can concentrate on restoring this one. I'll let you know (and reopen this task) once this is done.

In T392781#10773574, @LucasWerkmeister wrote:

Should be done, I think – please check :)

I see two pieces of secret information so far: [...] wosretbot/nonpublic.toml, with user name(s) to exclude from certain notifications? I don’t really understand this feature; @Tkarcher do you know what it does?

@LucasWerkmeister: I agree with setting up a new bot, but as Wosretbot is still active on a daily basis (only certain parts are buggy), I'd rather set up the new bot and password before the adoption and share the bot password with you via a secure channel, so you can replace the file instead of deleting it and ensure a smooth transition.

Glad you're OK! 😊 Take your time. I'm sure there will be plenty of work left (and/or to fix 😬) when you come back.

Bad news, I'm afraid. 😕 M-J was temporarily blocked for a couple of weeks in February in de-wiki and did not return after that, and also didn't react to my message on the talk page last week. I have a rough understanding of the plan outlined in the roadmap above and think I can implement it, but didn't want to start working on it yet as I was still hoping M-J would return and pick it up again - which probably will not happen anytime soon. So I'll start looking deeper into it in the next days.

Any update? Or is there anything I can do to expedite the process?

In T389540#10659244, @bd808 wrote:

Problem 0 here is that I can't find anything that looks remotely like a license inside of /data/project/request and the tool pre-dates the selection of a default license at tool creation time.

Merged on 2024-05-21. That's nearly a year ago. Maybe the view was there but dangling until recently?

The errors started shortly after that: Last successful run was on Jun 10th. Took us a while to notice it, and then some more time to actually start the adoption process.

I have no idea what the replacement for that is.

According to https://www.mediawiki.org/wiki/Extension:FlaggedRevs/flaggedpage_pending_table, we should probably use the flaggedpages table instead

@Mr_Tortue : Looks good, thanks! @M-J : Any update from your side already? Is there anything we can support you with?

Update available now in the development branch: https://gitlab.wikimedia.org/toolforge-repos/erinnermich/-/commit/10879f0216c0ed21c2614c6a44e085c441b4a843

Bot is renamed now:

The bot I created two weeks ago for the French Wikipedia is indeed called RappelleMoiBot (so grammatically correct), but it would be easy to globally rename it to Pense-Bôt. And I like the idea! :-) Any objections, @M-J ? Otherwise, I'd request the renaming.

Feedback from the user mentioned above: Did neither work with the primary browser (Safari) nor with a second one (not specified). But answering on my discussion page works, so the problem seems indeed to be limited to edits via Visual Editor.

Another report from the German Wikipedia:
https://de.wikipedia.org/wiki/Benutzer_Diskussion:Tkarcher#Frage_von_R2d345_(18:12,_31._Jan._2025)
(I just asked for more details)

Comment from @M-J copied over here from Gitlab:

Back to Phabricator after failed attempt to use Gitlab issues...

Moved to https://gitlab.wikimedia.org/toolforge-repos/erinnermich/-/issues/1

Sorry! I migrated Klexibot some time ago already, but forgot to close this task here. I see the bot running on Kubernetes:

I didn't even officially request access to the tool yet and already got my first task assigned. 😂 Thanks, I guess...

Migration completed successfully: Erinnermich is running on Kubernetes now.

German mentor here, supporting this proposal (after aligning with my fellow mentors here). And if it's too complex to solve in one step, we'd suggest to start with the following first changes:

Why is this column needed anyway? One of our mentors already expressed her resentment about this kind of forced transparency (here, in German), and I don't see a significant advantage of having this data collected on this page. Can we remove it completely, please?

No need to apologize. I'm aware of the upcoming migration since a couple of months and even tried to do it for my tools back in May (?), but failed due to my inexperience with Kubernetes and decided to (temporarily) settle with the Buster alternative instead. I'll give it another try soon.

No need to apologize. I'm aware of the upcoming migration since a couple of months and even tried to do it for my tools back in May (?), but failed due to my inexperience with Kubernetes and decided to (temporarily) settle with the Buster alternative instead. I'll give it another try soon.

The same error is back again (as reported in various discussions in the German Wikipedia).

Ah, ok. I somehow missed this second string. Thanks!

Not sure whether this is worth a new task: The newly activated mentor dashboard in the German Wikipedia is shown as "Mentor dashboard" in the top navigation, although the correct translation ("Lotsen-Verwaltungsseite") was already added months ago: https://translatewiki.net/w/i.php?title=MediaWiki:Growthexperiments-mentor-dashboard-title/de&oldid=10241188

known consequence of wikitext not yet supporting multi-line comments.

I understand why some might find the current syntax hard to use, but claiming tables or other things cannot effectively be embedded in talk page comments is just wrong. Taking the original example from above:

A new link was added yesterday, and I just tried it myself: The task type is still available:

Huh? I just corrected the description, but according to the log, I also changed Prio and Subcribers?! Sorry about that, don't know how this happened.

I'm pretty sure it's the Vector skin: I can reproduce the problem in all browsers both logged in and logged out, but it's gone once I switch to any other skin.

Another report. First edit by a new user. And yes, he/she confirmed to also use a browser plugin.

I'm dumb. Or need a coffee. Or both. Text is correct.

Reported again in https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/R%C3%BCckmeldungen#Bearbeitungskommentar

Ah, thanks - I didn't know about that one. But wouldn't a change of the rendering engine also fix T212085?

To add a current example to the discussion:

Also happening in the German Wikipedia:

This issue (Citoid replacing given URLs with the ones found in meta data) does not only cause problems with anchors, but also with sites using short urls in their meta data:

Yes please! And while you're at it, please also consider adding a warning ("Your new value is not the preferred value yet") or even adding a checkbox ("Set this entry as the new preferred entry") when entering new values (as suggested here: https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Wunschparkplatz#Hinweis_auf_Bedeutung_der_R%C3%A4nge_bei_der_Wikidata-Eingabe)