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

The videos are too large, usually 3 GB+. I really don't know why it sometimes fails on the server side or gets stuck at <var>X</var>% for days, or sometimes uploads lightning fast.

Great. I'll take a look at my other tickets and edit them accordingly.

@Peachey88 , why did you remove these tags? If this is something that should be done every time, the Video2Commons tool should probably be changed.

Phabricator does not exist to list tasks related to vanity projects.

Phabricator does not exist to list tasks related to vanity projects.

No more discussion, so tacitly, the community is still in favor.

If you use your Wikimedia credentials via OAuth, just see here: https://meta.wikimedia.org/wiki/Global_rename_policy

Yeah, there are definitely different calendars in use around the world, often in tandem with Gregorian, but we don't use any of those for timing when things enter the public domain due to the WMF and its servers being based in the United States.

Pardon me for being so dumb here, but are you talking about words or just the number like "1929"?

This is not a forum for proposing new projects. If you have a new proposal, go to https://meta.wikimedia.org/wiki/Proposals_for_new_projects

For what it's worth, this would be valuable to projects like Wikidata and Wikifunctions, where the page model of the vast majority of content is not wikitext, thus making many SpecialPages unusable (e.g. UncategorizedPages on Wikidata).

I'm inclined to say that "more pretty pictures with less text" is superior to "a couple of pretty pictures with some text-dense boxes" so I am inclined to keep the front page more like how it is currently. But that's a weak preference, not a clear must-have. It would be nice if we had some kind of UX testing to confirm "Users can get the information that they need with [Design X] faster than with [Design Y]" or somesuch, but I realize that takes time and money. Maybe a microgrant from the WMF is in order?

Came here from the post on en.wp's Signpost and I have looked over comments here. Is there a way to make an HTTP redirect from "https://mastodon.wikimedia.org/" to "https://wikimedia.social/"? Furthermore, it seems like "https://wikimedia.social/" should be some kind of landing page for any and all social media profiles and a Mastodon instance would be best at "https://mastodon.wikimedia.social/", but I suspect that ship has sailed.