Echoing @Bugreporter in response to @kostajh : No RFC is needed to make this feature available.

Updating description to note that the second FR has already been resolved. (conveniently matching Aklapper's rename to reflect only the first FR :)

In T246901#9226554, @brion wrote:

So if we add server-side rendering, we need a clean way to sandbox it, that works both in standalone installs and via Thumbor, and can be relatively sensibly managed and packaged, and made disableable with a switch-flip.

This makes my week. Thank you :) (:

Roy: it seems to me soft-blocking the /36 would only not have collateral damage if the block message indicated that one can still make an account or log in via IPv4, else people who only use mobile / hotspots won't understan what's going on.

Thanks for making a ticket. For me 2+ bits of essential information would be

Cool, thank you. I didn't realize a template could target a specific skin, though it makes sense that it's an environment variable.

I updated the request to be clearer. Right now the following reader use cases see single-column references: 1080px windows, or 1350px @ 120% (main menu open), and 1350px windows, or 1680px windows @ 125% (both menus open). This falls within a sweet spot of common use cases that affects both editors and readers, and is a width range within which two columns @ 25em still seems preferable to single column @ 50-60em for viewing references.

Yes, that matches what I'm seeing:

• main/toc open, tools hidden: 1100 | 1210 | 1310 | 1420 px at 100|110|120|133% zoom
• main/toc and tools open: 1350 | 1500 | 1620 | >1680 px at 100|110|120|133% zoom

My unscientific attempt to test how long it takes to toggle the pref from scratch, starting on es. ;)

Yes, thanks - one of the hangups being the lack of prefs for anons (which I deeply, deeply appreciate is being worked on now.) I clarified my comment above.

Aha, thanks for the pointers! I didn't know the accessibility project would do more than typography. The reading-settings panel mockup looks practical and lovely.

Polar Bear image: V2022 | Zebra prototype

Related: T332731 (last comment was "review this again in the context of the Zebra #9 prototype" )

Ouch. This and the lack of public updates about dark mode (with technical discussions explicitly private) feels disconcertingly open-ended. Other than the 150+ people chiming it to say this is important, what sort of research into importance to readers needs doing? How can those who see the need contribute to that research? This does not need to be a big deal; it can be implemented as a [client-side] user option at first if the concern is causing confusion for those who don't expect it, &c.

The left and right menus now start at the same page-height, which is a nice change.
And other visual zebra elements (Color contrast, &c) look good.

I suppose T44725 is too all-encompassing for what you have in mind?

@Bugreporter I updated the description with your examples, thanks for the added clarity about the current state across a range of projects.

Thanks both for the explanations. If there are graphs that are hard to convert to V5 and don't get converted, it would still be useful for someone to run a one-time sandboxed render in V2 and use the resulting still images in place of the graphs. [since some were created years ago and no longer have maintainers to come update them by hand].

Thanks on all fronts, that note is a good concise summary.

For more on Our World in Data, and people already working with its formats, see the discussion in T301044

Agreed that this could be a fine opportunity for a proper collab with Our World in Data. The underlying snapshots of graphs could be refreshed quite infrequently, say once a quarter, and still be tremendously valuable and a great improvement over what we have now.

1. It has been so long that it would be good to have a stopgap rerender of the removed graphs as static images. Is there a convenient way to do that en masse?

Looks like it is still 2-3 reqs/s. Is that the target usage rate? A fine metric for a query service is that it is used to its desired load. If underused, it could be made open-auth until this is reached, and then somehow have a conversation with those users re: options for rate limiting or uptime degradation.

Any activity that requires making an active choice, that other users can see (to observe whether the timing, language/selection/&c seems normal) makes moderation easier.

Is https://di-content-separation.web.app/Moss still the latest?

If switching from https to interwiki links gets a ~4:1 compression ratio; could both these and template links be further encoded down to a few-character redirect? maybe a companion table (or an R: namespace in WD ;)? Trading off space for query rewriting

Please don't blanket-oppose such a review system, just help make it good :) I'm not sure how variant 3 supports abuse, any more than those reviewing editors could already make such edits themselves.

@MusikAnimal is this still patch-welcome and of wishlist-interest but needs a community patch?
Or did the analysis turn up some complication?

Related: I have often been travelling, editing on mobile, and connected to the internet through a blocked IP range. In those cases, there was no way to edit or propose an edit or make an account.

@Skizzerz any further thoughts on the patch? is this just waiting for implementing suggestions and rereview?

Definitely useful to communities I'm close to! Came across this recently in a wikicite / shared source metadata conversation.

Thanks, that's the bug I was looking for. Yes, I can make it happen logged-out also, on a different browser.

Yes, this affects me too. It's not just "between 999px and 1000px" it is scaled up w/ browser zoom. So at 150% zoom it's "b/t 1497px and 1500px".
Any time I resize my browser window past this threshold, at something other than 100% zoom level, I notice this as an outsized flicker.

This is still happening for a few pixels of width right around the scaled equivalent of 1000px, at some browser zoom levels (900px @ 90%, 1100 px @ 110%, 1250px @ 125%, &c. ... but not at 50% or 100%).

@Addshore thank you for writing that and resurfacing your old post. Agreed that recon should be core to Wikibase, both for it to reach new users and to make setting up new small projects easier.

More generally, pref-changing could be part of a flow state. Switching to a prefs page and not being returned to the page of origin can be frustrating. (I'd love to see stats on how many people fail to complete prefs updates, or to return to the prev page, or just end their session.)

@Jdlrobson the original proposal was a pair of links in the identical place in the sidebar. (possibly with a confirmation popup, but no switching URLs, and the only page refresh would be to load a different skin). When implemented that way it is fast to switch, and clear what just happened and how to switch back. (It's not a novel idea; many products present a "switch back" toggle during a new rollout in this way)

Zotero seems ideal. Thank you!

♡, may also resolve T214802

Confirmed w/ Mek @ IA that there should be no problem hitting their /isbn endpoint at 5rps.
We may want to start with OL as the primary resolver, and only fall back to Worldcat if OL doesn't have full metadata for that ISBN - especially if WC continues with its quota system.

In T336297#8842993, @Samwalton9 wrote:

OCLC is moving to a new WorldCat API version, and unfortunately migrating Citoid to this API would require both a new agreement with them and some additional technical work.

I see, thanks. I was confused by the different overlapping threads in the discussions above.

@Jdlrobson I like this idea for coordinates. It's not for nothing that geodata is a special class of thing in many systems, including databases and articles.

I don't see the problem on eu anymore, are you still using your js solution? What's a current example?
en:wp has been using absolute positioning and not tagging coords as an indicator; needs to switch.

Comment from a discussion this week about "what workflows the wikiverse means to support" and "what Commons is for" (vs. other free-knowledge media collections): it occurs to me that "what file formats can be discoverable shared as free knowledge" is not a Commons question though it is often simplified to "what can be uploaded to Commons" --> "what current {Commons + WM} workflows can easily support".

Agreed re: just offering 90/180/-90 for under-X-MB files. Raise that to 20MB and you'll cover most good/featured images.

For cleaner stats this could be made symmetric for the two possible states:

For color: randomize the button colors, and (if you can manage it) the order in which they are presented.
Try both this and tooltips as different treatments of a sample of the same population (logged-in or logged-out) for better understanding of preferences.
Try this as treatments for a sample of both logged-in and logged-out for contrasting understanding of those two populations.

@Legoktm @Ladsgroup it seems crop and rotate (by 90/180) are such a common use case they should be "on" by default, whether by closer integration of CropTool into the upload wizard or otherwise.

@DLynch that's a very cool viz indeed, thank you for sharing. That can be quite useful on desktop too (see also: how well used the collapse templates are!)
I hope we can get some indentation solution on the roadmap.

I like a combination of 2 / 3 / 5:

@Jdlrobson : still the plan?

Bawolff: Most of our projects are built on external resources we don't control, backed up by web archives we also don't control. The threats you mention are rare events we already cope with on the projects. (and we still manage to let e.g. wikivoyage maps render external layers)

A proxy service for calls to such caches of trusted + curated knowledge makes sense.
That doesn't seem specific to this OWID use case, is there an existing proxy library that could be generalized or extended?

Summarizing some concerns raised, and responses to them in the discussion:

Great! I see I have to work on my phab-search-fu.

Thanks @Gehel for catching the duplicate.

What a fantastic QOW improvement! Beautiful, fast, cleanly integrated into the special page. Thanks @Esanders

Alex: yes, a bit of compression will make it easier to leave 1-2 more items in the personal tools links w/o other design changes.