I've also tried Wiktionary and Wikiquote, with the same error.

It seems the same error happens on English and German Wikipedia. Is this not working across all official Wikimedia sites?

In T246901#9836655, @PantheraLeo1359531 wrote:

In T246901#9836182, @John_Cummings wrote:

Hi @bvibber thanks so much for picking this up after 4 years, I'm not a wizard so I don't really understand your updates, but if there's anything muggles can do to help with this please let us know :) E.g I'd be happy to start a list of open license repositories for full colour 3d models

There you go:

• Poly Haven: https://polyhaven.com/models
• AmbientCG: https://ambientcg.com/list?category=&date=&createdUsing=&basedOn=&q=&method=&type=3DModel&sort=Latest
• Sharetextures: https://www.sharetextures.com/models
• https://threedscans.com/
• https://3d.si.edu/cc0
• https://github.com/nasa/NASA-3D-Resources
• https://3d.nih.gov/entries/3DPX-016621 (example)
• Internet Archive(?)

:)

Very active discussion here: https://phabricator.wikimedia.org/T246901

FYI, this issue of a stale staff/contrators page came up organically in this conversation around the Annual Plan:
https://meta.wikimedia.org/w/index.php?title=Talk:Wikimedia_Foundation_Annual_Plan/2024-2025&diff=prev&oldid=26823520

For the 2024 Hackathon in Tallinn, I prototyped an example virtual tour using the underlying Panellum software, which takes a JSON definition file for nodes, images, and hotspots. An example can be seen here:

I agree having a one-click setting for the base of a prefix would be useful. At the very least, we should dissuade anyone from using wd: wdt: et al. as is done in Wikidata. That's only going to lead to more confusion, as it is highly likely that anyone who is using Wikibase will likely have Wikidata experience and will be interested in federating with Wikidata. Having "wd:" be ambiguous out of the box seems like bad practice. On more than one occasion, I've had to coach a GLAM organization to not keep the wd: prefix, as we don't have great documentation or elaboration around the pluses and minuses of this decision.

Here is a longer "pitch" that is meant for the morning pitch session.

FYI, some conversations about finding folks to help migrate it over are taking place here:

FYI, this bot seems to be dormant as of September 2021.

In T319953#9392450, @tstarling wrote:

In T319953#9392014, @Fuzheado wrote:

Therefore I have only recently noticed that it is at risk of being deleted.

I don't think it is at risk of being deleted. I think the worst-case scenario is that the tiling job stops working. This would mean that old images will continue to work as usual, and new images would be shown with a maximum resolution of 4000px width.

The tiling job was broken between 2021 and October 2023, and apparently nobody reported the issue.

I kindly request that you extend the life of this tool to the February 2024 deadline. We will attempt to migrate it much earlier than that, preferably in December.

I just noticed that the message at ores.wikimedia.org seems to imply we are 2 months away from the classic ORES REST API disappearing and everyone needing to use the LiftWing service. I'm wondering if there is still a plan to hard stop at the end of December 2023.

In T246901#9054129, @Kristbaum wrote:

Here is a proposal on Commons with quite a lot of interest in the topic: https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Enable_textured_3D_files_on_Commons

Interesting idea - did you have any thoughts on how long each section summary should be? Would it be proportional to the section length? Fixed length? User definable with a slider/parameter? I used to do an exercise with my students to summarize a long article in SIX WORDS and only six words, so this project certainly is intriguing.

Seven years later, I'm tempted to surface this for the Wikimedia Hackathon 2023, or at least discuss the best possibilities using open-source tools.

In T335039#8793566, @TheresNoTime wrote:

FYI maintainers, I've restarted the webservice and the tool appears to be available again :-)

In T138933#8390562, @TheDJ wrote:

https://gitlab.wikimedia.org/hartman/panoviewer

I also found a new library worth exploring called panolens.js

In T315153#8151965, @AsPJT wrote:

I just checked and it seems to be working fine in my environment.

In T321702#8435818, @EChetty wrote:

Update:

• Yonatan (wikimedia Israel tech lead) explored using the MediaRequesst API and confirmed that it can replace the s3 storage they are using but will take significant refactoring on his side to get it working to reduce the size of the postgress instance (which is the main cost driver). He is unable to do any major refactors in the coming months.

• As a stopgap solution we are looking to migrate the project from AWS to cloud services. This however will require a minimum of 2 x 200GB instances. Need to request quota increases from the cloud services team before proceeding down this route.

Seems to be OK now, but I agree with @Dominicbm - these intermittent errors will crop up for 10-20 minutes then go away, but it's not clear whether they are being noticed or tracked by the folks on the search team. Any insights would be most welcome. Thanks.

In T306603#7870772, @Lucas_Werkmeister_WMDE wrote:

Works for me now; I also don’t think UBN! is appropriate for WCQS in general as long as it’s still in beta.

Looks like someone fixed it and it's back.

In T295043#7753056, @rook wrote:

I would vote we move to Jupyterlab. As staying closer to the default usually leaves us with a more stable project.

Agree, here's the specific error coming back:

There has been a response on meta to this from the WMF: https://commons.wikimedia.org/wiki/Commons_talk:SPARQL_query_service/Upcoming_General_Availability_release#Follow_up_response_to_WCQS_Authentication

FYI, related announcement - https://commons.wikimedia.org/wiki/Commons:SPARQL_query_service/Upcoming_General_Availability_release

In T290300#7349048, @Zbyszko wrote:

On the other hand, we have been affected by this greatly, when maintaining that service - we don't have an effective way to block or limit users that cause or contribute to issues with the service stability. We made the decision to use an authentication in WCQS so that we won't have the same limitation with another service we maintain. I think this will help us as a team do a better job of keeping WCQS running smoothly.

I'm going to re-up some conversation around this, by observing a few things that have changed quite a bit from 2012. Now that Wikidata is the center of gravity for a lot of what we do, the community is working with more data sets than ever, whether it is for OpenRefine or GLAM work. We have tangible needs for sharing data sets within the movement and collaborating on them with advanced tools. So this would argue for not just settling for using Github or external sites, but to actually allow the storage of (reasonable) data sets using formats that are recognized as being a best practice.

In T219354#5072120, @Chicocvenancio wrote:

In T219354#5071568, @Psychoslave wrote:

By the way @Chicocvenancio, what about making most popular module preinstalled?

I don't know how popular tensorflow is among PAWS users, but surely they are module that are popular and that would be convenient to have installed out of the box.

Its a trade off, every new package pre-installed into a server means a larger startup time and greater resource usage for all servers. In general I would want to use the minimum number of packages, while leaving novices able to do their work without an added step. Tensorflow, in my view, does not add sufficient value for novice users to offset the added usage for every server startup.

Thanks for this work @Legoktm - very cool way to get it working. It does indeed work and is showing the documentation here: https://asgi-test.toolforge.org/docs#/

FYI, @yuvipanda and @Chicocvenancio did help get Voilà running on PAWS as part of the Hackathon.

In T244847#6406407, @Pintoch wrote:

On my side, I would be keen to transform the wrapper into a Wikibase extension, but lack the skills to develop in the MediaWiki environment. It is also a significant risk to invest energy into this without being reasonably confident that it will end up being deployed on Wikidata and Commons.

Possible basic query for all participants in the 2020 Summer Olympics:

This would be great: @yuvipanda has been super helpful during Wikimedia Hackathon 2021 on improving the capabilities we have on PAWS and how we might publish standalone apps better to the community. Hope we can make this a priority.

A longer summary of the issues I wrote up and posted on Commons:

This conversation about how to do bot additions of depiction metadata, and attribute them appropriately in Wikidata vs Commons, might be useful here as it is what spawned the recent interest in this topic.

In T281419#7078370, @Nes wrote:

Hello @Fuzheado and thanks a lot for proposing this session!

We would love to schedule it on the main hackathon track on Saturday, 22nd of May at 19:00 in UTC. You would have 55min, questions and discussions included.

Does this timeslot work for you? We kindly ask you to confirm before May 17th, so we can complete the schedule.

As a speaker on the main track, we will send you a link to a BigBlueButton room where you will be able to present and share your screen. The content of your session will be live-streamed on a video platform and automatically recorded. Participants will not be able to talk to you directly, but they will leave comments in the chat. We will send you more details closer to the event. If you’d like to schedule a testing session to have a look at BigBlueButton, just let us know.

If you have any questions, feel free to reach out to me. Thanks!

Hi @Chicocvenancio @Daniel_Mietchen - Wondering if there's anything we can do for the upcoming Hackathon related to this. Or, is enabling something like Voila practical as part of PAWS?

In T281420#7077030, @Lea_Lacroix_WMDE wrote:

Hi @Fuzheado @Susannaanas and thanks for proposing this session.

We would love to schedule it on the main hackathon track on Saturday 22nd at 21:00 UTC. You would have 55min, questions and discussions included.

Does this timeslot work for you? Who else would be involved in running the session?
We kindly ask you to confirm before May 17th, so we can complete the schedule.

As a speaker on the main track, we will send you a link to a BigBlueButton room where you will be able to present and share your screen. The content of your session will be live-streamed on a video platform and automatically recorded. Participants will not be able to talk to you directly, but they will leave comments in the chat. We will send you more details closer to the event. If you’d like to schedule a testing session to have a look at BigBlueButton, just let us know.

If you have any questions, feel free to reach out to me. Thanks!