FWIW, https://zoomviewer.toolforge.org/index.php?f=Blue_Marble_2002.png&flash=no does work for me as of now (Firefox 118.0, Windows 11).

In T102776#7165809, @Jdlrobson wrote:

This would need to be a skin specific preference as skins decide layout.

Reported again from Safari/MacOS here.

In T235332#6067156, @Jarekt wrote:

Adding SDC would be also nice, but with so few pages in that namespace I do not see it as a high priority.

Great, thanks everyone!

Thanks, I have made a request for somebody to add that piece of code to Commons' Common.css.

Possibly the same as/related to T132467?

In T166094#8310375, @TheDJ wrote:

I have some other points that should be taken into consideration

1. Having a default alt tag, will increase the size of an img transclusion on pages, which seems something to keep an eye on.
2. Review... In much the same way as default content from wikidata was a problem for en.wp, I suspect that default content for alt tags from Commons might be a problem for that community. It would be the first text content from Commons that by default becomes part of wp articles, sourced by search engines etc. There is a vandalism angle possible there, and they may argue that Commons' review processes are not setup to detect that, so that might become a conflict point.
3. Per the law of levels of investment required to get something useful... This is likely only to benefit en.wp in any sort of substantial level. Other languages will stil mostly be left out.
4. It could be a distinguishing feature to have multi lingual alt text of very popular media items.

In T166094#8307437, @Pigsonthewing wrote:

In T166094#8202790, @El_Grafo wrote:

1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

In T320337#8306171, @Pelikana wrote:

On commons we want to have the option to enable all thumbnails completely, not mocked up pseudos like cropped squares. To give image researchers fast ways to overlook their search results seeing the exact image contents as miniatures, including all edges. For example to see if it is a landscape or portrait format. Thumbs of image files on Commons do need this special attention compared to thumbs on other projects.

I feel like we're missing some essential tags on this ticket as it has gotten zero response so far. What's missing?

In T313638#8250458, @Herzi.Pinki wrote:

the solution for this (allow the deletion of false coordinates) is only half way. In principle the bot copied it, the bot shall keep it in sync without user intervention.

In T166094#8166800, @Pigsonthewing wrote:

There were several significant, detailed objections, which were not refuted.

Similar behavior is being reported at Commons:Forum (permalink): Existing coordinates cannot be changed (in Firefox) because the "Publish changes" button is greyed out. Switching skins (!) helps temporarily; problem does not exist in Edge.

Confirmed: rank changed but existing qualifiers removed. Who is responsible for this tool?

Village pump proposal now archived here: https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2022/05#Adding_alt_texts_through_structured_data

Confirmed, same happening for me.

Wish I could claim that for myself, but it was pointed out by CptViraj here. Sorry for the false alarm. It seems Commons is OK with importing this kind of file in principle, but it would be good to alert the importing user about the situation.

Wait, it seems the import was done by another user, not the blocked one. That changes things. Apparently the user importing the file was not aware that the original uploader at the sister project was blocked at commons. I guess there should at least be a warning?

In T307213#7895264, @Aklapper wrote:

(Random wikis can have random templates with random names. I would not expect MediaViewer to know about all and any of them.)

Just realizing that this is a duplicate of T68606 ...

Hey, just some quick points a I currently don't have the time to go any deeper:

This seems to be yet another instance of T201111. Sometimes it works, sometimes it doesn't.

No idea what the original issue was, but it seems to work just fine now. Can we just close this?

Sounds like a good idea.
I suppose from a technical POV (thumbnailing etc.), images in this format could be treated as simple JPG files that just happen to have a file extension that's different from the usual jpg/jpeg/JPG/JPEG for now?

I can only speak for myself, of course:

Seems to be an issue related to Internet Explorer: Using IE 11.0.85 on Windows 10 and the WLM-de campaign I get exactly the issue described above, and the preview thumbnail is missing as well:

See also (and feel free to join) this current discussion at commons (permalink as of today). According to @Bawolff most of the security issues may no longer be a concern. The potential for malicious macros could be a blocker, though.

In T155290#4187962, @Smalyshev wrote:

have a "description" slot, and put categories there.

I think having a separate description slot, where you could put categories, templates, bot instructions, human instructions, etc. would be the best solution. Trying to make JSON into what it's not meant for is far inferior.

It's great to see this project finally gaining some momentum!

In T51443#1492162, @MarkTraceur wrote:

I think this is going to be obviated soon, with the emergence of more specialized upload tools for specialized cases like artwork. We should be able to do it more easily outside of UploadWizard.

While we're at it: 4k is on the rise and 8k is already lingering around the corner, so I'd like to propose adding these sizes as well.

In T167815#3350070, @Revent wrote:

In my experience (and I have somewhat failed in this at the past) the best method would be to start a simple 'discussion' about the perceived issue, suggest a solution, and then ask the community to debate the matter. Once there is at least some degree of consensus about the correct solution, then ask the community to actually vote on approving it.

The goal here (and I hate being so 'politicial') is to create a degree of investment in the community in solving the actual issue, instead of merely asking for a 'yes or no' to a specific solution.... if the community says yes, and then there are complications, the opinion will shift quickly to 'no' with blame applied to the proposer of the solution that proved to be problematic. We need a degree of community engagement with deciding what is the correct solution to the issue, so that the community has an investment in finding the best solution instead of simply saying 'no, that broke the world'.

With GeoJSON now being available in the Data: namespace at Commons, maybe converting to GeoJSON automatically during upload could be an option?

In T76011#3356142, @Whatamidoing-WMF wrote:

Having that geographical data would probably be useful to Wikivoyage, too. I wonder whether other projects could benefit from it. Maybe {{requested photos}} at the Wikipedias? And I could easily imagine some editors at Wikipedia (or other projects) wanting to search first for images from their own region: 'apples grown nearby' vs 'apples'.

In T76011#2723289, @Whatamidoing-WMF wrote:

Here are some things that the Commons wants to be able to search/filter search results by:

• metadata
• file type
• file size
• dimensions (maybe aspect ratio?)
• upload date

Same thing happened to me today at https://de.wikipedia.org/w/index.php?title=Wikipedia:Redaktion_Biologie/Bestimmung&diff=166406671&oldid=166404885
Timestamp in history: 09:08
Timestamp in signature: 09:06

In T120867#2503815, @Gunnex wrote:

In T120867#2501748, @El_Grafo wrote:

(...) Requesting wiki configuration changes says we need community consensus, so I suppose we should start an RFC at Commons:Village pump/Proposals?

@Gunnex wrote:
Probadly yes (but not by me).

Well, I have some kind of conflict of interest here, because probadly I provided the most content and data AGAINST this tool... so it would be nice, if someone else would open the RFC. Please... soon (Commons is flooded by currently around 500 cross-wiki uploads daily)

Wow. Looks like the mobile uploads disaster all over again (in case you don't remember, see Mobile upload needing check#Background). I agree with @Yann: This has to stop immediately. Requesting wiki configuration changes says we need community consensus, so I suppose we should start an RFC at Commons:Village pump/Proposals?

In T31793#2063867, @Nemo_bis wrote:

Why is this in UploadWizard? The upload checker should be generic for any upload method and it's not necessary for it to be part of MediaWiki even. A Python bot or web tool would be equally good, for instance.

Yes, the idea was mainly for file description pages, and I can't really imagine anyone objecting to enable it there by default (but, just in case of flying pigs, an RFC at Commons might be a good idea).

In T115318#1721533, @Bawolff wrote:

If its mandatory, what do you expect people to do if they dont know the answer?

User:MarkTraceur/editDescriptions.js pretty much already does this, at least for normal {{Information}} templates. You can test it by adding

@Qgil, @josephine_l: Volunteers have already forked (?) both the android and the iOS versions and recently published updated versions. See Commons talk:Mobile app#Re-born!. It seems like the android version is looking for volunteers, though: Commons:Mobile app. You may want to get in touch with User:Syced

In T113177#1672343, @Tgr wrote:

IMO there should be an "image options panel" where extensions and gadgets can easily add their buttons, much like mw.util.addPortletLink() for the toolbar, but as I said that's a bit beyond Media Viewer.