I think the simplest way to correct this error is to lower the maximum upload limit to 1 GB for validation.

I have the same problem uploading FLAC files, same error

Apparently it is not a storage problem but in the way the files are unified in a subsequent process, the temporary files are deleted without first confirming that the final destination file is created satisfactorily.

In T26070#9131701, @Esanders wrote:

In T26070#8401685, @Ladsgroup wrote:

I don't know if it should be a blocker or not but the dark mode being used in mobile frontend leads to scary pictures in search:

(it might not be a blocker as mobile is a different skin altogether?)

The solution here is to either add the classes used by the widget to the non-inversion selector, or to add the standard mw-no-invert class to the images.

The latter is a much better way to do this. Darkmode should not have to maintain a list of CSS classes by every extension that uses background images.

Do we really need years to modify a simple CSS? I wonder what the priorities are. Or are you guys applying the bad practice of if something works, don't touch it?

I don't have a URL for any of those images because this was in 2015 and I don't remember what names I gave them.

I underestand, I will upload the videos again in another place. Video2commons work but it stop sometimes Thanks

it would be a big mistake shutdown, it is a repository of RAW images of Featured Pictures in commons. Many RAW images would be lost or no possibility of being accessed from Wikimedia Commons.

The file need to be uploaded. Thanks

Same Problem when I try change to the translator to Google Translator{F34317019}

I have the same problem '⧼cx-mt-failed ⧽' when I try change from Apertium to Google Translator on a English to Spanish translation.

It looks like MW knows it's too big and just hasn't bothered

thanks Kizule for your support with the file mirror, and @Urbanecm usually, how much time take the thumbail generation?

this takes a few days before the image is actually updated, thus making it impossible to correct image defects during a nomination process for a Featured Picture on commons, for example

the same with https://commons.wikimedia.org/wiki/File:Jard%C3%ADn_(1044347743).jpg

Same error message today in this file:

Well, thank you very much guys. I will wait patiently for this problem to be resolved some day

How much it could take?

I cant login with any user or any password. I tried to reset my password but its told me that the username not exist

It can be done anytime, Im waiting

Friday is ok to me, that way I'll have the weekend to fix something that needs to be changed

Matiia or anybody, please, do it on any moment. Thanks

Thanks Marostegui, please let me know if you need something else and feel you free to contact me, take care by yourself

It could be done on any moment, preferably a Friday. Thanks

Its a global rename, spanish wikipedia and commons have more edits

In T215107#4922851, @Legoktm wrote:

Can we not rename users with large edit counts back and forth (c.f. https://meta.wikimedia.org/wiki/Special:GlobalRenameProgress?username=The_Photographer)? Will this be the user's last rename request?

Thanks in advance

Same problem, I cant upload my images because this problem, also with Uploadwizard with images TIFF with more 600Mb of size (TIFF with internal zip compression).

to me the image is not visible on Wikipedia spanish

I created this script based on your script

/*
 Transform "Upload log" page in a Gallery
 "Upload log" page: https://commons.wikimedia.org/w/index.php?title=Special:Log/upload&user={{YOUR USERNAME}}
*/
$(function() {
    'use strict';

Thanks Nirmos, however, it is something that should be done on server side.

Krenair, thanks. It was a permission problem, now it's public. You can use simply:

Yes yuvipanda, the right word is tool, thanks

You can upload the file here
https://commonsarchive.wmflabs.org

You can upload the file here
https://commonsarchive.wmflabs.org

You can upload the file here
https://commonsarchive.wmflabs.org

You can upload the file here
https://commonsarchive.wmflabs.org

You can upload the file here
https://commonsarchive.wmflabs.org

You can upload the file here
https://commonsarchive.wmflabs.org

You can upload the file here
https://commonsarchive.wmflabs.org

Well, I deleted all in my personal configuration page and it work now

Watchlist is cleaned now, however, could be better some kind of limit in this list. Thanks

This functionality is extremely necessary

In T86785#976911, @Tgr wrote:

This bug is not actionable. You should either specify what change in behavior you are expecting (T6745?) or come up with a different organization for the page (such as subpages) - the problem that too many people try to edit the same thing at the same time is ultimately not a software issue.

*Mozilla did a study of various lossy compressed image formats. HEVC (hence BPG) was a clear winner by a wide margin http://people.mozilla.org/~josh/lossy_compressed_image_study_july_2014/. BPG files are actually a little smaller than raw HEVC files because the BPG header is smaller than the corresponding HEVC header.
*BPG natively supports 8 to 14 bits per channel when most other formats use 8 bits (including most of the JPEG implementations and WEBP). It gives a higher dynamic range (which is important for cameras and new displays) and a slightly better compression ratio (because there are less rounding errors in the decoder).
*BPG uses high quality decimation (10 tap Lanczos filter) and interpolation (7 tap Lanczos filter) to handle the chroma samples in 4:2:2 and 4:2:0 formats.
*BPG can be supported in hardware with standard HEVC decoders and encoders (it uses a subset of the Main 4:4:4 16 Still Picture Profile, Level 8.5).