With all likelyhood, this is the reason:

The way to fix this would be to add a dummy prefix like "Wp/qqt/" to the page name in the test. What's the best way to do that?

Okay, so here's what I'm thinking for the stats/cron job (again with the disclaimer that I don't really know the limitations/capabilities of Dash especially):

• Make the query check one calendar month at a time; save the results to e.g. stats/YYYY-MM.tsv
  • Generate similar stats for previous months of 2022?
• Run the query as a cron job once a month (1st of each month) to create a new results file
• In the tool (or in the query, but I think it might be easier to do in the tool?), we can do some logic to check the number of consecutive months of activity per project.

Works properly on https://incubator.wikimedia.beta.wmflabs.org/

OK from LangCom.

This seems unproblematic.

The way I imagine this would be to have a parser function called {{#wikidata:}} (the name is obviously just a suggestion). So for any page on the Incubator that is about Norway, you would add {{#wikidata:Q20}}. The availability of this parser function should be limited to only a small number of wikis, via a configuration switch in InitialiseSettings.php, let's just call it wgAllowWikibaseAssigning, which defaults to false, but can be set to true for the relevant wikis (maybe also only allow it for a limited set of namespaces?). For enabled wikis, the parser function should do what the description says; for all other wikis, it could either just show up in plain text (like {{SHORTDESC:}} does outside of enwiki), or just not show at all, or not show, but add a tracker category. The latter would be useful for bots to connect articles to Wikidata items after a wiki has been approved and exported from the Incubator to a proper separate wiki.

Fixed.

@KCVelaga Can we meet in the Workadventure space to discuss? :-) I'll be in the "Localization and small wikis" room when I'm online (like now).

In T307147#7900300, @KCVelaga wrote:

@jhsoby as I am trying to do some initial data exploration. I have some questions:

1. When a new wiki is created, do the pages and edits related to that wiki while on incubator get deleted or are they kept? This will be helpful filter out edits from the revision table by rev_deleted parameter. From what I understand, we will only need the dashboard for wikis are currently incubating, but not all historically. We will need some initial way of filtering down to edits belonging to current wikis rather than loading the entire edits data. We possibly do with REGEX from page-title, just wondering if there is an easier way.
2. Any thoughts on how we can remove incubator related edits, such as edits related to actual incubator related pages such as main page, FAQ etc.
3. About stats to be collected: how about adding, number of pages as well?
4. do you have specific endpoints/frameworks in mind for the dashboard?

Also, about live/monthly, depending on how big of a dataset we end up, we can setup a weekly, bi-weekly or monthly update.

With today's rollout of the replacement gadget (AddPrefix 2.0), I think this can be set as resolved.

@KCVelaga Awesome! I see you list SQL as one of your skills, and that's perfect, because that's a big gaping hole in my skills, and definitely needed for this. 😊

Would it be possible to just disable the VE accesskey if the wgAction is edit or submit?

Ah, sorry, I was confused then. Thanks for clearing that up.

In T259224#7595115, @Nikerabbit wrote:

Could also investigate whether we can get alerts on the translatewiki telegram channel which would relay them to IRC as well.

10 years later …

Works as it should on https://incubator.wikimedia.beta.wmflabs.org/ .

In T299980#7800708, @bwang wrote:

Trying to make the accesskeys work for hidden links in the user menu would increase the complexity of our CSS, and might have accessibility implications (i.e. a duplicate hidden link could be available to screenreaders).

In T299980#7757977, @Jdlrobson wrote:

It seems access keys must be visible on the page to work so I am wondering if instead of an access key for the user page button, we could wire it up so that any access key of menu items are used we trigger it. Having to use 2 access keys - one to open the menu and one to select the item seems a bit of a cop-out. We might also want to consider hiding the menu via some other mechanism than display: none

Yes, they are shown as blue links now. \o/ Thank you very much!

\o/
Thank you very much!

Thank you very much! :-)

I was mostly looking at the messages mentioned by Ooswesthoesbes in the Support thread on Translatewiki, which are related to the changes from this task (it's difficult to parse what happened there, but I think the end result now should be OK).

Oh, and sidenote: I noticed that Sumanah is listed as a maintainer with her @wikimedia.org address – since she hasn't worked at the Foundation since 2014 and has no Gerrit activity since 2013, I think it would probably be wise to remove her.