In T315022#8252408, @awight wrote:

It might be interesting to log events from TextSlotDiffRenderer, and gather some metrics from each document pair. But there's already a basic StatsD metric MediaWiki.diff_time. I made a draft dashboard to explore, please feel free to take this over and improve. I think it shows that there are approximately 30 diffs run every second, and the vast majority take less than 2ms, but there's also a constant stream of long jobs which take 5s, and can sometimes go up to the 60s timeout.

Interesting. Is the max always capping at ~60s 'cause everything beyond that times out?

I've created T318086: Create phonos Jobs to handle mass file generation

So as it turns out, we do have a way to rate limit a job via $wgJobBackoffThrottling. It could be set to something like $wgJobBackoffThrottling['phonosGoogleEngineSomething'] = 1000/60 (TBD). It should be less than the actual limit so to account for regular edits, previews, etc.

In T316009#8232966, @TheresNoTime wrote:

The quota increase request includes a text field marked "Your description will be sent to your service provider and is used to evaluate your request. It's useful to include the intent of the quota usage, future growth plans, region or zone spread, and any additional requirements or dependencies. " — I'm happy to write this, and would primarily be giving an overview of the Phonos project (linking to https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Generate_Audio_for_IPA ?) and touching on the possibility of reaching out separately to discuss burst quotas. Is there anything specific I should mention and/or should someone else be writing such a request? Perhaps @NRodriguez or @KSiebert?

@tstarling is there something specific I should be testing for to better gauge performance between the different engines?

I've created the above patch (DO NOT MERGE) and here is what I found so far with the very limited data that I'm testing against

Memcache could have been an option if we had stick with the API approach. Right now we (will) return a path to a file at parsing time so we need it on disk
See T315481: Call IPA Engine from parser hook

Noting that deleting a file is a separate process and it currently does not show any messaging when the talk page is also deleted. This patch doesn't change how File Deletion or Undeletion show their messaging on success.

Thank you for filing this, from our understanding this will never happen on production and really only affects dev envs or when you are globalizing users as part of the central auth installation.

Has this been resolved?

Some questions

In T313711#8103757, @Samwilson wrote:

One advantage of only supplying text is that the Google quota usage will be much lower.

This being said, since the Gadget will be eventually removed-- we will not pick up any bugs associated with the gadget.

This is the main reason why I brought it up. As long as there are no issues with it I don't see a problem keeping it around until we are done.

It will not but we should probably notify plwiki about it since it'll become disabled by default and they'll need to opt-in. @sgrabarczuk any suggestions?
I've created T313420: Remove Realtime Preview Gadget and enable Realtime Preview on plwiki via config.

@NRodriguez should we start thinking about removing the gadget from plwiki? Any particular reason for keeping it at this point?

I'm sorry, this was my bad. It was only for testing purposes and I've reverted the edit now.

In T309797#8002662, @JMcLeod_WMF wrote:

@dmaza, can you note which wish was picked in a comment here?

Pageviews on Help:IPA and subpages for all wikis in the last 30 days.
Grand Total is 1,758,387 across all projects.

Sort of a duplicate of T187584: Investigation: Using log_search to query for logged actions against IPs in a given range. Maybe the discussion should continue over there?

We were hoping to work on this in tandem with the IPA wish, but after discussing the various implementation options we've concluded that it will take a bit more effort than initially anticipated. We'll put this back in the backlog and pick something with a smaller scope to work in parallel with IPA

In T305268#7933964, @dom_walden wrote:

@dmaza Is this supposed to work for Files as well (File_talk pages by default can have subpages)?

In T305268#7934566, @dom_walden wrote:

@dmaza I wonder if the link to Special:PrefixIndex for the associated talk page should end in a /. This is what we do with the link to the page's own subpages.

For example, this page currently has a link to Special:PrefixIndex/Help_talk:Cite_errors. Perhaps it should be Special:PrefixIndex/Help_talk:Cite_errors/.

The latter would mean we wouldn't include the page Help_talk:Cite_errors itself nor any pages which happen to start Help_talk:Cite_errors but are not subpages.

In T305268#7920162, @TheresNoTime wrote:

Discussed on slack, related to a $wgNamespacesWithSubpages config change — not unexpected behaviour for this change then :)

In T307793#7910014, @TheresNoTime wrote:

Is alt+) meant to open the panel or reload the preview?

Well now that you ask, it was my understanding that it was suppose to reload the preview (that must be why it is bound to the reload btn). But then there is this task T307473: Shortcut does not open Preview first time so I'm confused. @NRodriguez @nayoub ?

I would like to add that the shortcut is not working on a MAC. Should I create a different task?