Well, if we need to have better support for multimedia, first we need to give some attention to the existing system that is basically falling apart. Let me give you some examples.

Thumbor, the software that builds small sizes of the images is on deprecated infrastructure, on EOL python version (python2), uses an extremely old fork of the upstream and does not have an owner. And this is a pretty critical software, if it goes down, virtually no image can be shown in all of Wikipedia (including all SVG files). Because of that, we can't move it to a newer infrastructure (kubernetes), make it use a more modern python version or upstream code, to make it use a more modern version of svg converter to fix countless svg bugs the current system has [1]. It in itself is blocking adding more features on all of Wikipedia. For example, as a certified science nerd, I want to add support for chemical markup files (.bxr, etc.) that would enrich our chemistry articles [2] but well, it's blocked on thumbor being unmaintained.

The old video player, kultura, is still in production and used quite heavily. The replacement media player exists but has some bugs that are rather easy to fix and unblock further rolling out. But because no one is on this task, it's basically a group of volunteers (including yours truly) struggling to find the time to work on it. [3]. It would give a slightly more modern look to our media player.

This is mostly fixed but worth mentioning, the image table in commons was bigger than 300GB compressed (and 600GB uncompressed), it would take 15 hours to take a simple backup and basically a ticking bomb given how heavily it is used. Commons went readonly and caused a big outage so technically it was a bomb that exploded already once. The problem was metadata of pdf files and djvu files were massive, the pdf files got fixed by Tim Starling and I (I did it in my volunteer capacity) which in turn reduced 200GB from it. And now we are working on fixing djvu. [4] Again in volunteer capacity. This work is actually blocking redesign of the image table to make it more useful [5] or practically any change that would impact size of tables in commons.

The problems have passed the point of blocking improvements and adding more features, they are reaching the point of actually bringing down our systems and bleeding to the rest of our systems. And it all boils down to not having a dedicated team on multimedia but in all fairness, it's not something you can fix overnight. You need to grow, hire, plan, etc. etc.

[1] https://phabricator.wikimedia.org/T193352#5984544
[2] https://phabricator.wikimedia.org/T18491
[3] https://phabricator.wikimedia.org/T248418
[4] https://phabricator.wikimedia.org/T275268
[5] https://phabricator.wikimedia.org/T28741

On Sun, Oct 17, 2021 at 1:08 PM Juergen Fenn <jfenn@gmx.net> wrote:

Am 16.10.21 um 16:25 Uhr schrieb Yaroslav Blanter:
> In a few years, there will be tools for editing video. If by that time
> we are not ready to incorporate video at full scale to Wikimedia
> projects, we will be where AOL is now.

We already _are_ there. When we tried to relaunch German Wikiversity
almost ten years ago we sadly had to shrug and decline offers to bring
converted classroom scenarios to Wikiversity because Commons did not
accept mp4 videos and we could not include frames from YouTube where it
all happens. Period. That was the end of online learning with Wikimedia.
(Fair enough, there were more reasons why we did not succeed.)

BUT: When we incorporate multimedia content at full scale it should be
clear that Wikimedia is NOT YouTube. We won't accept everything. We need
high qualitity educational content. Only.

Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/MROKQ7DVULD6JJQEVCFCKKPU3K2KEUVP/
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org

Amir (he/him)