After the update to iOS 13.2.3 the problem went away. So I guess we'll chalk this one up to a browser or OS bug fixed by an OS upgrade.

Thanks. I hadn't yet been prompted to upgrade from iOS 13.1.3 (it seems sometimes the carrier backplane configuration is a little slow on that for initiating the prompt), but will try on 13.2.3 and report back later (gotta run now). Meantime, see the attached animated GIF for w:Main Page, followed by a timeline recording captured a little later. Both from pristine freshly instantiated app and browser instances in private mode. In my timeline inspector it implies that initial handshake is around 500ms (although for some reason I can't seem to hover on it). Anyway, looks pretty fast. I tried a larger article on a presidential candidate and that didn't seem to be a problem.

It seems (?) like all of the network transfer (including TLS handshake, first page, subsequent assets) from this timeline recording happens within 1.5 seconds. That part's okay (even though I wish TLS handshaking and the networking subsystem went faster!). The waiting for layout part, though, at about 8 seconds, seems like it may relate to something with style recalculation, no? The timeline doesn't suggest anything unusual in terms of CPU usage (not sure about memory pressure, but I typically only have one app active).

In T238342#5708124, @Gilles wrote:

Have you tried Desktop Safari with a computer on the same WiFi network?

In T238342#5707128, @Gilles wrote:

Since you were able to record it, was it consistent? Can you still reproduce this reliably?

Kicking over to Mark as manager of the Structured Data engineering team, where maintenance of FKA Multimedia team projects is performed.

Relevant: T203127: Implement "last known good version" API

@cchen copying you in for visibility. iPad iOS 13 is a desktop UA, in case that's useful info in other contexts.

Access requested for me - dr0ptp4kt

Hi team, I found one reviewer somewhat serendipitously. @pmiazga will provide a review of https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/EventStreamConfig/+/545654/ and this has been okay'd with @ovasileva provided it flows through the Web team's workboard per usual process. @pmiazga see T233634#5664331 for the context - much of the architectural specification has already been worked out over the past months, but @Ottomata is looking for conformance to good MediaWiki PHP conventions and sensible API endpoint and field names.

Thanks @Ottomata. I see the note from @Krinkle on the patch about the other gating, where you're sure to get some additional good feedback.

@Tgr do you know if this one is a simple fix or does it look more complicated? I incidentally was trying the API out this morning and happened to come across this task.

Hi @Ottomata, @phuedx is unavailable at the moment. What were the parts of the patchset where you were hoping for most attention? I ask so we can try to find an appropriate substitute to review.

@Halfak, ah, thanks, here you go:

Upon second thought, I'm not sure this really needs mwparserfromhell just yet. No point letting the perfect being the enemy of the good, either. Patch posted ^, please do let me know in case of any questions.

Related: T234865: Spike: Does our current pageview data identify whether browsers are non-JS?

While <textarea> based editing ought to continue to work without JS, yeah, getting an understanding how much editing happens that way without JS would be helpful as a proxy.

I'd like to thank everyone who contributed to this discussion and commend the Web team on taking into consideration the tradeoffs. Looking forward to the results ahead.

@MarkTraceur I filed this request - you should probably be the one to manage the request given you'll be project managing the contractor, but let's discuss. Feel free to edit the request, as I may be not thinking holistically enough...or I may be thinking too holistically!

Pasting in an email I sent:

@Yurik good point. I think the guidance for use of the functionality will necessarily need to note such complications. I imagine instrumentation would be the fastest path to flagging particularly slow cases for remediation.

@Yair_rand agreed the relatively larger JS component size is not ideal. We'll need to compensate with deferred/lazy loading. As for the comparison of the different media types, also agreed on the notion that there's a qualitative difference between static rasters of graphs that wouldn't have follow-on interactivity and plays of video/audio - this is more to note that JS as a requirement for some non-wikitext content is somewhat normal. Video and 3D have a raster, too, it's just that the stuff is intended to be played to enrich the experience. It's certainly a tradeoff around maintenance cost versus the benefits of inbuilt static rendering.

@kzimmerman possibly, depending on time pressure. I just set up a meeting for tomorrow to discuss with you and Connie.

Resolving

For those still following along: I haven't forgotten about this. Looking at this a bit more, I think mwparserfromhell parsing of templates will improve this hierarchy a bit further in addition to relaxing the regex. I'll be interested in upstreaming this stuff hopefully sometime this Q2 or next.

@Milimetric the visual treatment depends on a few factors, although yes, I think we'll want a placeholder to account for any deferred / lazy fetch or client compute timing things.

Thanks @kzimmerman - yeah, some cursory review of the "predicted" values and whether they're approximately sensible and whether addition of stuff of this nature to Hive for a starting point might be of use would be most appreciated!

I'm about to start the work to derive country from Infobox settlement bearing subjects (effectively replacing the Geography.* mid-level category assignment for such subjects), as that's something we're exploring for the purpose of counting pageviews by topic in a little more fine tuned way as a starting point, but meantime here's what the heuristic output looks like.

Hello all. We're going to turn this into a client-side feature and divest of the server side rendering componentry.

The intent here was to capture the material captured via T102318: Convert startup blacklist to feature test with richer detail and on an ongoing basis.

We're mulling this over still.

Thanks! Okay, expanding the heap size helped here. Thank you for the offer of assistance as well!

Okay, let me look into this.

@ovasileva okay to redirect Safari desktop to mdot?

Here's approximately what I had in mind. The mwparserfromhell library might streamline extraction of key-value pairs, but this gets at the typical whitespacing patterns and it seems editors typically follow convention for parameter ordering.

@Pchelolo I may have missed it but has a standardized persistence mechanism been defined?

I'm in support of permanent stashing.

Thanks @santhosh and @Pginer-WMF. Lydia and I spoke. Just to close the loop on one my earlier questions, template key-to-Wikidata property association does not clash with Wikidata client editing plans as of now. Lydia also reinforced the value of data mining in working through potential futures (some of which is happening I see). There are no simple approaches, to be sure, but I did want to close the loop on this one item.

Hi team, just to follow up on what I've let some of you know by email, I'm going to investigate the option of finite temp resources to help handle the more pressing item on EOL to buy us more time. We'll need to scope narrowly so that we address the EOL problems at a minimum and hopefully sidestep any further challenges like this in the future.

Hi @Bouzinac, usually the software tries to make basic web page rendering functional without a strict need for JavaScript. Obviously a significant portion of the software actually requires JavaScript in practice for a feature rich experience, but basic reading is one case where usually we want to be able to support the basics.

Approved as Engineering Director.

I'm in support of the canonical identifier of template parameter keys being Wikidata properties in the cases they're available. I lean toward TemplateData for the time being as the place to forge the connection between template keys and Wikidata properties. As people inevitably copy TemplateData templates across wikis in the current state that ought to make for more consistency on the semantic meaning of the templates, at least.

@diego @Pginer-WMF thanks for the earlier replies on this task. I had some annual planning and vacation stuff that drew me away for a while, but just wanted to say thanks!

@chelsyx I forget some of the details, but I think it's okay to allow the multiple domains be the referrer for the pageviews.

Hi all. There isn't further work on this. Right now the Multimedia team is focused on the Structured Data on Commons project, for which the grant runs until the end of the current calendar year. Presently additional work on stuff outside of SDC or urgent bugfixing or adding test coverage is generally lower priority. Tagging @Ramsey-WMF for any further prioritization or work decomposition if time becomes available in the new calendar year.

Thanks @chelsyx!

Thank you, @chelsyx, great work! Is there a Phabricator paste or Jupyter notebook with the queries and results for our future selves?

Hi @eranroz. Heads up, I'm on time off so my reply may be delayed a couple weeks.

I was wondering, how well does the parameters name-based approach apply to the set of TemplateData-backed templates themselves?

One of my hopes is that people will be concentrated together on topics. I'd prefer single track with a well structured format if at all possible.

Thanks @kzimmerman. All the signals I've seen and that we could think of seem to suggest there's a positive traffic increase attributable to the intervention. My gut instinct given typical user behavior on search engine result pages and the nature of this intervention is that there's very little cannibalization, no detrimental cannibalization, and in fact there's a real boost to content availability and consumption.

@elukey thanks for the follow up here. No need to block on me for the GPU. Fully agreed on the need for a secure supply chain.

As an example, https://upload.wikimedia.org/wikipedia/commons/thumb/7/7f/NY_308_in_Rhinebeck_4.jpg/800px-NY_308_in_Rhinebeck_4.jpg maps to https://ms-fe.svc.eqiad.wmnet/wikipedia/commons/thumb/7/7f/NY_308_in_Rhinebeck_4.jpg/800px-NY_308_in_Rhinebeck_4.jpg in the cluster if fetching directly from stat1005.

To clarify, was that via the internet or internal cluster?

@Nuria the other day I mentioned my project around use of DeepSpeech.

@Yurik in addition to pulling both version of the JS for pages bearing both v1.5 and v2 syntax, the other thing is to encourage the syntax being updated, is that right?

Thanks @elukey

Totally understood on the user observed performance (at least when it's on the critical rendering path) and static asset payload, just wanted to make sure if it's the case that theoretically JS-only provides all of the functionality (for JS clients) and there wasn't some additional use case.

Hi all - we had a meeting on this and a question emerged. Is it possible to run Graph without Graphoid if the clients are JavaScript-only?

Hi, I'm requesting access to gpu-testers as well in order to begin validating model building.

Thanks. Confirmed it works.

Okay, this has been sitting in draft for too long, so I'm going to provide this simply so that we have it here and people have access to some queries in case they're looking around later. I was intending to share some numbers then follow up about product aspects on a separate post. But I've been rather busy with planning and anticipate continuing to be quite busy with more planning. We'll be discussing potential product / support aspects separately in a forthcoming meeting.

@JKatzWMF @JMinor would you support us addressing T142090: Add hover-card like summary (og:description) to open graph meta data printing plain summary as time permits here in Q4 or perhaps as a Q1 FY 19-20 project, to bridge the gap between now and bigger social sharing work?

• Based on 1A, the volume of visits coming from integrated translated results in Google search is similar to the visits explicitly requesting a translation (e.g., by going to Google Translate or clicking the "translate this age" option in the search results).

Correct. And note that this graph only shows the traffic when the translation target language is Indonesian. You may also notice that from January to February, visits from integrated translated results is much higher, then it drop since March. I asked @dr0ptp4kt and he thinks Google probably change their algorithm.