Aside: the link to DB2Rest should be db2rest.com (github)

Why are the details about the problems sites see so vague? 😅

That looks great, thanks @Quiddity. Deserves more visibility than just your user-css :)
Perhaps there's also a css-only solution to T328847 ?

Still the most-tokenized open issue :)

I see, alas! As with T364545 and T334941 I find V22 less polished at lower-width windows on desktop; I regularly use two-up windows on a laptop, so I run into them. Do you get feedback / polled data from readers with smaller windows?

Ran into this in compiling a newsletter this week. :) Only realized on finding this ticket that someone has had such good + quantified success. https://phabricator.wikimedia.org/T18691#6019615

Thanks gwern. I can see a single classifier working for our purposes, if it supports an 'uncertain' middle ground. just need to tweak where the threshold is drawn.

A family of solutions here, or even one flexible one, would be very impactful.

+1 to this idea. If there were a canonical image associated with the audio file, as there is in most catalogs, that could be the default poster to display which would be overridden by this setting.

Has there been any recent progress on this? T348269 by one of the preeminent reusers of SDC, in both scale and impact, seems relevant; but that remains untriaged and this one is High but unassigned.

you might try a mixture-of-classifiers, which all have an 'uncertain' range between yes and no:
0 - is precise color the point?
1 - does inversion look good in dark context?
2 - is there a color key in the text?
3 - other (non-standard inversion?)

Many technical problems are also social problems, this seems like a definite antifeature + I hope it is ok to keep the ticket open while addressing the social component.
@valerio.bozzolan I also do not recall any global discussion about how range blocks should affect various trusted users, and it is indeed a regular source of difficulty.*

@Jdlrobson @Dwain_Zwerg renicing this -- what is the proximal obstacle to updating the default?

@Gwern wonderful application, and agreed that this should be by URL and not by chain-of-reasoning.

One reason is that citations are a large corpus with a fairly narrow range of schemas and uses, so it could conceivably be implemented with optimizations that can't be applied across the board. But I do think that after a split into a separate citations wikibase, we should then formally evaluate the split and consider whether re-merging after a migration to a new graph db makes sense [I would hope it does -- 1B entities is not too much for a single db in other communities and contexts]

@Michael forgive my confusion, isn't part of this being able to use one Repository with multiple Clients, or to enable WikibaseClient to draw from both a local Repository and the global Wikidata repository?

aliu: absolutely right. Thanks for continuing to engage on this, and your generally constructive approach :)

For en:wp, this seems to differ from WP:Statistics by a factor of two. (looks like the latter shows ~500 articles/day)

It seems Naypta is not around. Someone else has tentatively offered to take over bot maintenance, and could use guidance, see this wiki discussion.

it *is* important that the solution be secure and performant.

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

But: it would be nice if one didn't have to use mobile web to use the app. Since sometimes mobile web has issues that need workarounds, which might be why one is using the app in the first place.

Aha, let's see: I have CiteHighlighter, CiteUnseen, MoveToDraft... and NeverUseMobileVersion 😅 That would do it.
I added that last year to work around a different problem, since fixed.

@Jdrewniak that looks like a fine use of clamp.

And: Android 14, confirmed in app versions from 2023-12-12 and 2024-01-22

Nice to see you @taavi, hello to you too. That was my question! This should apparently be directed at @Naypta? My mistake. Just trying to avoid a confused-yet-avoidable limbo for this tool, which is still warmly in use at least on en:wp. :)

Just asked on yapperbot's talk if it was down due to gridengine migration; I see it is. @Naypta are you around to respond to the comment there? Does the bot need adoption?

In T334940#9480339, @TheDJ wrote:

As far as I can see, there are only a few options right now ?

This is how it would work at any moderately sized tech company.

Earlier in my career I was a Principal Consultant at a $1B software company. I didn't find the environment anything like this.

Hello @MMiller_WMF, thanks warmly for tackling this. We seem to have a solution to the immediate problem (rendering static images), but have not implemented it.

Do you see indications Graphs will come back this year? This is the third time we're back at square one considering static options. This could have been done from day 1; doing it now is better than 6 more months in the future.

That's it! Can happen at most resolutions, not just 150%, but more prominent the larger the zoom.
And search stops working (which is noticeable even on pages with TOC and main menu hidden)

Aha, thank you ! Yes, that's the difference, I was looking at pageviews, not mediaviews, on Wikistats. Interesting to see the gaps on the two ends of the spectrum between pageviews and mediaviews, and that it's not always in the same direction.

@RobinLeicester : I hear you. But I was only proposing a highly constrained fix to the immediate problem, generating static images once, for the ~20k? graphs that existed at the start of this year and are currently broken or missing.

@cscott and @Tgr now that reenabling the extension is on hold for heavy-use performance reasons, and not security reasons, can the sandboxed approach be used to generate static images of all graphs?

I see, many thanks @jwang.

• On getting data per user, or bucketing groups of users: I hope this is developed as an option. There are many privacy-preserving ways to do this, some I know have been implemented by other teams in the past, and it can complement per-session statistics especially when exploring what works for new accounts that may only stay briefly.
• From the breakdown, I see that 90% of logged-in users who customize their experience do so to turn off page previews. That is not so surprising: it actively impedes reading if you aren't used to it / are not careful, and the toggle to set a preview preference is right in the middle of the preview pane, taking up 1-2% of the total pane in the center of a reader's gaze.

Thank you @jwang! I missed that.

Thanks! I started a discussion here on en.wp, please leave a note there when resolving this :)

Reproduced on Android:

On whether this closes the fr: a share link isn't really a "toggle between desktop and mobile" even though it is flexible, and I think that should be a primary feature for editors: who constantly need to see both views. I'd still love a persistent link back and forth accessible to logged-in readers. Having to scroll to the bottom of desktop/browser view to get back to mobile/app view is also frustrating.

Hello, this is on Android, where I use Chrome as default. Let me see if "share to browser" works ... it does! Nice.

Thanks for the link! That's presented in a rather confusing way, I'm not quite sure. (A little data-journalism would go a long way. :)

The first two seem to be the same data, shown two ways.

Yes, that's helpful. Thank you. When a group like Amazon talks to (non-Enterprise) WMF folk about technical changes that would simplify their use of the site, I wonder if there is any mechanism for converting that to a free-knowledge-coalition membership, formalizing the link and providing a bit of funding.

This would be wonderful. It's disconcerting to see a list with many redlinks in mobileweb have none in appview, I usually have to doublecheck that I'm on the same page before remembering the issue.

Yes, looks like that solves this. Thank you, Sam. Thoughts on making this accessible to WP editors by default?
Ideally I could see this being integrated into What Links Here.

@Pppery So close! :) Perhaps there's a related question for Wikispore if it becomes similarly popular and people start looking for other incubated efforts.

Given periodic enterprise interest (T316618) and suggestions they are already hitting existing API endpoints to do this (in an inefficient and costly way?), could Enterprise help normalize this? @FNavas-foundation what do you think

Hello @jcrespo and @Mitar -- thanks, this does clarify.

@Xaosflux - how has T19929 been adressed since that bug's creation? How much is that still a parent task for this?

@Jdlrobson mild protest at this merge -- I don't want to edit this report, but the more visible design bug (though not a search-functionality regression! + maybe different resolution) is that the entire top 1.5 screens are given over to the left sidebar + TOC, which cannot be hidden :)

Yes, no change: 999-1000px at 100% zoom, 1498-1500px at 150% zoom, &c.
Try manually changing your browser window until you see the flicker at the crossover-width.

@Jdrewniak thanks for the update. Is there also a separate css property for the TOC linespacing?