In T427081#11955438, @A_smart_kitten wrote:

In T427081#11955347, @Andrew wrote:

The site is back up; the VM that hosts it had run out of disk space.

I still personally experience the 301 to 127.0.0.1 mentioned in T427081#11950084, FWIW.

In T427081#11950084, @A_smart_kitten wrote:

As of right now, for me at least, https://wikitech-static.wikimedia.org/ has permanently moved to... my localhost (ie., 127.0.0.1) :P

$ curl -I https://wikitech-static.wikimedia.org/
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 23 May 2026 07:09:21 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: http://127.0.0.1/wiki/Main_Page.html
Content-Security-Policy: : default-src 'none'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'

For what it's worth, https://www.wikimediastatus.net/ says "All Systems Operational". I don't know of any other tracker to see if a WMF site is down. If I'm missing something, let me know.

Snaevar, maybe the functionality wasn't obvious, but you could click on a button at any Wiktionary entry, record in your browser, and then immediately upload to Commons and add it to the entry. It was seamless and worked incredibly well. :/

In T206942#11904734, @Redmin wrote:

This does not seem to be relevant anymore as all audio files on enwikt appear to have been moved to Commons in the meantime: https://en.wiktionary.org/wiki/Special:ListFiles?limit=250&user=.

In T421796#11888089, @Ericliu1912 wrote:

在T421796#11888041中，@ZauberViolino写道：

There are now excessive vandalism and promotion on some Wikinews editions and we may have to confront with them. Maybe considering changing to admin edit-only mode for a few days.

I endose the idea for letting admins do some final cleanup. It would be a shame for us to simply let Wikinews (especially those with a smaller immediate-active community base) forever disgusted by the vandals in their final moment and unable to do anything to save them.

Thanks. The above method mentioned at https://en.wikinews.org/wiki/Wikinews:2026_Wind-down_Wikinews#Infoboxes

! In T421796#11825027, @Pharos wrote:
maybe as an transitional step we could disable new-page creation for a couple weeks before going totally read-only?

In T421151#11808897, @Lydia_Pintscher wrote:

It's probably not great to treat some one way and others another way.

Related: T421797

Related: T421796

Related: T421724

Related: T421796

See also T413619

Note that the above links to some user-generated reports which have been deleted or changed. To see the most up-to-date version of these user reports, go to https://en.wiktionary.org/wiki/User:Jberkel/lists/wanted

Is this connected to SUL?

In T409686#11358315, @Base wrote:

Doesn't outreachwiki already cover this scope?

This evidently causes some issues for editors trying to get around Mainland China censorship: https://en.wiktionary.org/wiki/Wiktionary:Feedback#What_happened_to_en.m.wiktionary.org?

In T405777#11221427, @Ladsgroup wrote:

First needs approval from the board.

In T391747#10876090, @Dzahn wrote:

"ported over" sounds like an existing wiki is being imported. Is that the case? The ticket does not seem to mention this so far.

I watch the page creation log at Incubator, but if someone could do the courtesy of explicitly pinging me when this wiki is ported over, I can delete the content from mul.ws.

I watch the page creation log at Incubator, but if someone could do the courtesy of explicitly pinging me when this wiki is ported over, I can delete the content from mul.ws.

Weird. It *did* in fact upload at https://commons.wikimedia.org/wiki/File:President_Trump_Delivers_Remarks_at_the_Governors_Working_Session.webm

Ah, what timing. Please feel free to close if you feel like this is redundant. Thanks.

Thanks. I'll mark this closed.

What should I do then?

This is nonsense. Please do not make blank feature requests or bug reports.

Note that there is now a local list at Commons for very large files: https://commons.wikimedia.org/wiki/Commons:Very_large_files_to_upload. This can be used in the future if/when the maximum upload size is increased.

Now listed at https://commons.wikimedia.org/wiki/Commons:Very_large_files_to_upload

Now listed at https://commons.wikimedia.org/wiki/Commons:Very_large_files_to_upload

https://commons.wikimedia.org/wiki/Commons:Very_large_files_to_upload

In T382859#10428690, @Bawolff wrote:

Personally i believe that such lists of files to upload when the limit increases should instead be on commons. There is probably thousands of such files, and their url might change in the next decade. Not to mention that this process might not even be the correct process in a decade's time (One certainly hopes in a decade upload by url would be stable enough that the upload would be done directly on commons).

I think it would be better to create a list on commons of all the very large files waiting to be imported. It would make it easier to sort through and maintain then potentially having thousands of tasks for files that we likely aren't going to be able to upload any time soon. Having all these tasks on phab that cannot be actioned on makes it difficult to see what work needs to be done in the present.

In T382859#10428600, @Bawolff wrote:

In T382859#10426482, @Koavf wrote:

In T382859#10425996, @Zabe wrote:

The current max file size is 5GB (T191804).

Then this may need to be a child bug to a parent that is about increasing the max upload size so it can just be put on a list of files that could/would/should be uploaded when the max size is increased.

Perhaps this task should be declined. It is unlikely we will increase the upload size further in the next 5-10 years, and i don't think it really makes sense to have server-side upload tasks just be waiting around in limbo that long.

Is it possible to make T382859 a child to this? Thanks.

In T382859#10425996, @Zabe wrote:

The current max file size is 5GB (T191804).

Correct: mul.ws is now supported thanks to the hard work of the fine developers here. Thanks for clarifying.

Redundant to T378318

Redundant to T378318

Redundant to T378318

In T54971#10259809, @MGA73 wrote:

Okay I understand that there are some concerns about the content of beta.wikisource. So if sitelinks are allowed then at some point someone will add links to content on beta.

But sitelinks are also used for templates like GFDL and for that reason I see benefits of allowing beta.wikisource to use sitelinks on wikidata.

So who wins? The yes or the no? Or is there a way to allow one and not the other? No clue. But now I said it and perhaps that can inspire someone to find a solution. :-)

Courtesy link: https://en.wikiversity.org/w/index.php?title=Wikiversity:Colloquium&oldid=2666876#'Edit_to_my_talk_page'_notification_bug?

Wow, weird. Thanks.

In T376438#10201443, @Pppery wrote:

Koavf's link works for me.

And I cannot download the PDF.

I just downloaded https://en.wikiversity.org/w/index.php?title=Wikiversity:Colloquium&direction=prev&oldid=2661311 as a PDF and it worked just fine.

This is not the venue to lobby for your own wiki. If you have something that could be related to the mission of the Wikimedia Foundation, please see https://meta.wikimedia.org/wiki/Proposals_for_new_projects