This makes perfect sense. I've opened an issue for it on GitHub: https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/5195

Thanks Boyani. That's a potentially interesting idea, but I don't know whether any open source text-to-speech engines are good enough to provide a good listening experience — especially for the sometimes-technical content of the training modules. I'm unlikely to prioritize a project like this, although if you know more about how this could be implemented, I'm interested to hear details.

I've just deployed an update to staging:

I've made these updates and deployed it to dashboard-testing.wikiedu.org.

In T302584#8307540, @Daimona wrote:

@Ragesoss Hi, I have one more question about the endpoints at T302584#7751395. We already talked about replacing the "organizer_username" parameters with "organizer_usernames", that accept a list instead of a single name. I still think that would be a good solution for the confirm_event_sync endpoint, but I'm wondering if the parameter is necessary for the update_event_participants endpoint. Requests to that endpoint are made whenever the list of participants changes, which in most cases is an action initiated by the participants themselves. So I'm not sure if we need any authorization checks for that step, unless I'm missing something. What do you think?

Here's another example on English Wikipedia, a table produced by the "Track listing" template on https://en.wikipedia.org/wiki/Renewal_(Billy_Strings_album)

I've turned this off.

I've turned this off.

I've turned this off.

Sorry, I don't know what the previous agreement were and what was planned for V1, apologies if this wasn't on your radar. At any rate, I wasn't really asking for the possibility of adding multiple organizer to the dashboard with an API endpoint. I asked that because organizer_username is a required parameter for both endpoints, and I was trying to understand what value we should pass in case of multiple organizers in order to pass authorization checks. I think for now we could just pass the username of the event creator (assuming they are also a facilitator for that event in the dashboard) and it should just work.

• Organizers can also delete event registrations (and, in the future, restore them). Do we need to do anything special if that happens? It's not mentioned in the endpoint description above, but I was wondering if it's something that should be added

I think these should probably be independent at this point. It will make sense to add deletion-handling at the same time we add the option to create a Dashboard event automatically via Event Center, but in the meantime, since Dashboard events are created independently, users may want to delete an event registration but still use the Dashboard for their event.

🎉

@DimitriosRingas you can add Wikidata by clicking Edit Details on the Home tab, then putting Wikidata into the "tracked wikis" field and saving it.

To have it track Wikidata contributions, an organizer must add Wikidata to the tracked wikis. The event linked above is only configured to track el.wikipedia. Once Wikidata is added as a tracked wiki, it should show the additional edits after its next data update.

Here's another example I ran into: https://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&iiprop=url&iiurlheight=480&pageids=107709976%7C111662244%7C109767821%7C109782162%7C109782164%7C109782168%7C109782171%7C109782172%7C109782180%7C109782183&iilimit=50&continue=%22%7C%7C%22&iicontinue=Flag_of_the_Soviet_Union.svg%7C20070509050010

I was thinking, rather than expand the existing Cinder volume, it might make sense to mount separate volumes for other languages. We probably want to request more max storage, but spreading it out more would mean we don't have to mess with the volumes that are already working.

I'm currently working with a professor who got stuck on this while trying to create their account.

🎉

I'm closing this now, as (per my comment in the parent) I set up a new tool that provides the data I got from this endpoint, and it sounds like no one else needs it.

Thanks @eranroz. I didn't have any trouble connecting to the database from another tool, and I got a replacement for the API up and running.

I'm going to build a new tool to replace the plagiabot api; it's pretty simple and I can access the copyright diffs database independently of the plagiabot codebase, so this way I can hack on a webservice without messing with all the other things that the eranbot tool is still doing via cron jobs.

Yes, it's done.

I've been added to the eranbot tool and I've been poking around, but I can't figure out how to set up the plagiabot API webservice. The code seems to be all in order in terms of requirements, as the scripts that run against the same repo work, but I'm not sure how the webservice was previously configured.

Is the python 3 upgrade necessary to move the plagiabot API to Buster? Wiki Education Dashboard and Programs & Events Dashboard both rely on the plagiabot API (see T312790), and it's been down since the Stretch Grid Engine EOL.

In T112730#7970088, @Magnus wrote:

I think I fixed the URL for Special:OAuth, someone please try it in the wild

Thanks!

As of today, the Dashboard is still having edits blocked, like this:

Thank you @Stang!

After receiving a report of the service not working, I logged in and found celery down again. I've restarted it.

Invite sent, Dino_mann.

Thanks @Geertivp! I agree that this would be a good improvement. Unfortunately, the OAuth library that we use to handle the login process was written with the assumption of using a single MediaWiki instance for login, so it would take a significant rewrite of that library or some creative workaround to make it possible to make the login flow work based on browser language.

I think I did it! That worked far more quickly than I expected. Distributed systems are a miracle and a horror.

The Cinder volume that holds the database was full. I'm trying to resize it.

It looks like the database went down. I've restarted it, but I fear that I waited too long to expand the storage volume, which is currently at 96% full. Unfortunately, I'm on vacation and won't be able to work on that until I return home next week. Here's hoping it stays up until then.

I was just in an office hour meeting with several instructors, and this came up spontaneously again; student editors find it consistently confusing that the button in their sandbox says "Publish" because they assume that to mean "Publish to mainspace". Calling the button simply "Save" is perhaps not the right solution, but anything other than "Publish" would likely be a big improvement in the sandbox context.

I've deployed this to a test server, dashboard-testing.wikiedu.org, and can provide the API secret whenever the team is ready to start testing out integration.

One more update...

Found it! Your messages had gotten filtered as spam. I've sent you a Slack invite.

In T301731#7795345, @AmeyGupta wrote:

hi @Ragesoss ! I have send you the mail for joining the slack channel but I haven't received the reply so should I send the mail again?

Currently, it returns a slightly different response... now the code for the error is _1 instead of $1. It should probably be toosimilar instead.

Hi @AmeyGupta! Send me an email if you'd like to join the project's Slack channel.

@cmelo please have look at my proposed API signatures when you have a chance. If these look good, I'm ready to implement them.

@Ignexus nope, just the Slack channel.

In T301731#7760131, @Bikid475 wrote:

would love to work on this project.

I've gone through more of working through the API details based on the discussions. Here's what I propose. (Assuming that every Event Center user has an account on Meta, the wiki language/project isn't necessary. If that's not the case, then we'll need to add the wiki details as params as well.)

Noted, thanks! It presents a little bit of a design challenge, as the current table can't easily fit extra links, and I also want to be wary of making the interface too complex and crowded. But it might be worth it, as additional links would definitely be useful in some cases.

In T301731#7713582, @srishakatux wrote:

@Ragesoss Thank you adding the project! Would it be possible for you to add the details also here: https://www.mediawiki.org/wiki/Google_Summer_of_Code/2022#Ideas_for_projects?

@Hanna_Klein_WMDE I only have data for training modules that are on outreachdashboard.wmflabs.org. (Several of those are linked from that LerneWikipedia page.)

Sent!

@Hanna_Klein_WMDE please let me know your email (or send me a message at sage @ wikiedu.org) and I can send you the data.

I don't think you've given me usernames in the past, @GoranSMilovanovic . I've just run the script to generate updated CSV data of the same format I've sent you before. If that's what you need, I can email it to you now.

Thank you!

In T297520#7636714, @Whatamidoing-WMF wrote:

I don't know what your current training program looks like, so perhaps this is a useless question. You said that the documentation already explains this, and I agree with you about the value of documentation. Does your program present any information about the principle of working in public? Or explain that if they want to save something privately, they can save the wikitext code off wiki, and paste it back in later (just watch for straight quotes being "helpfully" turned into curly quotes by word processing software)?

Since this change was implemented, I have seen a few comments from new editors about this in the context of userspace sandboxes. I find that it communicates the point very clearly: if you click this button, anybody in the world will be able to see what you wrote. That people hesitate to click that button might be proof that it's working as designed.

In T297520#7635422, @Whatamidoing-WMF wrote:

What do you mean by "don't match up exactly with how Wikipedia uses those terms"? Can you give an example of "Publish" being used on Wikipedia in a way that means something other than "made available to the public"?

In T297520#7567353, @Jdforrester-WMF wrote:

Yes, I agree, the abuse of the term "publish" by tools to mean "move out of sandbox to make a live article" is extremely misleading and you should fix that and explain to your users that "sandboxes" and "drafts" are all published content that have all the related social and legal concerns that such a term implies. If you have copy from half a decade ago still using the term "save" you should definitely fix that.

Thanks @Amire80. I've filed a new task for it as T297520. Since he.wiki no longer users "Save & Publish", I guess the concept for this task of ensuring consistency across languages is no longer relevant.

In T163302#7563866, @Amire80 wrote:

In T163302#7563858, @Ragesoss wrote:

A terminology change that made it more clear that "Publish" for a non-mainspace page is not that same as "Publish to mainspace" would help a lot.

... But it is the same, except the namespace.

A larger problem is that newbies don't understand namespaces, and I can't blame them. I doubt that the label of the Publish button will fix that.

One thing that we've noticed consistently for Wiki Education program participants since the "Publish" label rolled out is that it's extremely confusing in sandboxes, because users take "Publish" to mean "move out of sandbox to make a live article". We've had many cases where users lost their sandbox work because they tried and failed to find a Save button but they knew they didn't want to publish their draft to mainspace and so avoided that button. Many users in this situation assume that, since there is no "Save" button, their draft must automatically be saved (since this is how many other WYSIWYG editors work).

You can set any of these as the home wiki. Each course/event can only have one home wiki; additional wikis should be added to the Tracked Wikis field.

Thanks, that's helpful. So this is probably breaking Wikipedia for like ~2% of Mac OS users, ~0.3% of overall desktop users? Yikes! (Plus about that many who are still on even older versions, which I guess were already incompatible with Wikipedia.)

I've gotten reports of users (two students in Wiki Education courses) getting an invalid cert error from visiting en.wikipedia.org. Is that perhaps because of some gadget traffic going to Toolforge while the user is on en.wikipedia.org, or are there also possible related cert problems on Wikipedia itself?

Thanks! This problem is based on using a browser-native default JavaScript confirmation dialog instead of a custom one built into the app; the 'don't show anymore' is part of Firefox.

Done, and I've sent Will the link to sign up as a co-mentor.