# Community Wishlist Survey 2022/Multimedia and Commons

Multimedia and Commons
27 proposals, 331 contributors, 678 support votes
The survey has closed. Thanks for your participation :)

## Improve graphs and interactive content

• Problem: Wikipedia would benefit from more animations, interactive content, and self-updating infographics.

When we discuss historical changes, we should be able to view those changes interactively, e.g. side by side. Statistical data should be represented as easy to understand charts, and when the new data becomes available, those charts should update. We already have some of the tools for this (the <graph> tag, the shared data on commons, maps), but the current tools are hard to use, not maintained, and need improvements. The comprehensive vision was presented several years ago in a short I Dream of Content paper.

The Graph extension has many advantages for Wikimedia projects. In brief, it allows data to by displayed by generating graphs on-the-fly (we do not need a picture file anymore, and so we do not need to create a new picture each time the data are updated). However, the Graph extension is currently not widely used, probably partly because the code is not really user-friendly.

In addition, the current extension has not been able to display Wikidata data for more than a year, and since there is no official maintainer for this extension, the problem may show up again in the future.

Develop a GUI Visual-Editor-like tool to help contributors to create nice graphs. This tool could look a bit like those in spreadsheet software (the user selects the data to plot and the type of graph, then fine-tunes it). This tool could be integrated with the Data namespace on Wikimedia Commons (example) and with the Wikidata Query Service. The latter already offers different visualisation methods, with the ability to export results to several formats (html, json, svg). See this example. Adding customizable Vega code as an output would be nice.

Community Wishlist Survey 2016/Categories/Multimedia#Support SVG interactivity and animation in Media Viewer discussed making animation and interactivity easier for SVGs.

• Who would benefit: Readers and content creators
• More comments: this proposal received the 6th highest number of support in 2021 and should be handle by the development team. Yet, it is not sure they find time to work so it may be valuable to propose once more this proposal because the problems are still present.
• Phabricator tickets: tag/mediawiki-extensions-graph, among which phab:T165118, phab:T100444, phab:T109630, phab:T151127 ...
• Proposer: Pamputt (talk) 11:20, 13 January 2022 (UTC)

### Discussion

• Hello Pamputt! It would appear this proposal is mostly a copy/paste of the 2021 wish. Things have changed since then, however. phab:T195627 and phab:T195628 have been declined because Graphoid has been removed from production entirely. I'm guessing phab:T165118 is the appropriate task now. Then where you say …the current extension has not been able to display Wikidata data for more than a year – this has been fixed, right?

Could you please review this proposal and make sure it is up-to-date? I'm also concerned it is asking for too many things. I think "Develop a GUI Visual-Editor-like tool" is a good wish by itself. Adding localization I imagine might be a big chunk of work, too, so phab:T100444 might also be a separate wish. (I know we didn't have you break these out into separate wishes in the past, but we're now trying to be more careful about over-promising). Thanks, MusikAnimal (WMF) (talk) 15:54, 13 January 2022 (UTC)

actually, one of the problem is the "graph" tag is enabled on Wikimedia project but there is no identified developer/maintainer for this tool so it is not really supported and bugs appear with time and are hardly fixed (that's why I've spoken about the major bug (hundreds of graphs embedded in Wikipedia articles and elsewhere did not display anything during that time) that waited for more than one year and half to be fixed). "graph" is a wonderful tool but it is complicated to use so this is the place to debate of that but the WMF should have a clear strategy about the MediaWiki extension that it deploys on WM projects; for example, one tool that is deployed should have at least one identified maintainer who is part of the WMF staff: no technical staff, no more extension.
In addition, the proposal has been massively supported last year and nothing has been done on it contrary to what was announced. So finally it is a lot of time spent by contributors to write and read this proposal and also by the WMF staff to manage all of this and in the end you get almost nothing but disappointment.
So I modified slighty the proposal and I will spent more time on it. If other people want to take care of it, do not hesitate. Pamputt (talk) 18:48, 16 January 2022 (UTC)
• There is an Vega 3.0 project at https://github.com/nyurik/vega which is made for MediaWiki. The project was security tested in phab:T172938, but the issues raised do not seem to have been fixed.--Snævar (talk) 17:56, 13 January 2022 (UTC)
@Snævar: This might be a good separate proposal. —TheDJ (talkcontribs) 15:51, 16 January 2022 (UTC)

### Voting

• Problem: When uploading images from places, there is an option to include informations about the place, where the image has been taken. Probably, the informations can be automatically entered if you use a camera with integrated GPS. If you use a camera without integrated GPS, entering the data is cumbersome. I need to go to another website (e.g. OSM) and copy the geographical coordinates from there and fill them in separately. There is an option to show the location, but it's only active after you havbe filled in the data to check them.
• Proposed solution: Include a coordinate picker in the Image upload assistent.
• Who would benefit: Users adding images from places and users, who want to check the geolocation of an item.
• More comments: Maybe, the map window opening could be directed from the category, in many cases, coordinates of the city are already axisting somewhere, so the coordinates picker tool would not need to start with a map covering the whole earth. Maybe, the existing location check window could be improved to move the marker for slight corrections and a tool to add the view angel could be implemented (usually I omit that because a had to try and error to find the correct angle.
• Phabricator tickets:
• Proposer: Mboesch (talk) 09:55, 20 January 2022 (UTC)

### Discussion

• If is category connected with Wikidata, it can use coordinates from this entry or coordinates of upper category. But there are also categories, where coordinates have no sense. JAn Dudík (talk) 09:59, 20 January 2022 (UTC)
• The batch upload tools mentioned in the next proposal had this feature when they were still working. JiriMatejicek (talk) 09:20, 1 February 2022 (UTC)
• I think some code for this was already written for UploadWizard a long time ago, but never finished. See task T58612. Nosferattus (talk) 02:50, 2 February 2022 (UTC)

## Bulk Overwrite Tool

• Problem: Currently many uploaded .svg files are significantly larger than necessary or contain source errors that make them invalid. It is easy to download and fix/improve multiple such files, but it is tedious to subsequently over-write multiple old files with the improved (though visibly identical) improvements. Users visit each file's page individually to overwrite.
• Proposed solution: Create a tool similar to UploadWizard or other bulk uploaders which allows file overwrite. Based upon the uploaded files, the tool should propose the files to be overwritten based on matching file names (and accounting for modifications that wikimedia automatically makes to names of uploaded files) and it should display old and new images side-by-side. While this tool should support bulk overwrites, it should still impose a step for the user to consciously confirm or correct each specific pairing of new file & old file.
• Who would benefit: Anyone who frequently edits .svg files to reduce file size or resolve source code validity errors ... or anyone who makes frequent fixes or changes to multiple image files.
• Phabricator tickets:
• Proposer: CdnMCG (talk) 20:56, 21 January 2022 (UTC)

### Discussion

I agree. One new tool should be able to achieve both proposals. CdnMCG (talk) 00:48, 28 January 2022 (UTC)
• so basically you would like to drop 20 SVGs into the UploadWizard and say "Yes" to a question like "A file with this name already exist. Would you like to update it?". If yes, I support this. --Valerio Bozzolan (talk) 14:54, 11 February 2022 (UTC)
That is basically a way of achieving what I envisioned. For images, the process should show preview tiles of both the new file and existing file. I would think it's harder to make mistakes when looking at old & new side-by-side. CdnMCG (talk) 18:24, 11 March 2022 (UTC)

### Voting

• Problem: Metadata of images is constantly being improved thanks to crowdsourcing, either on the database of a GLAM or on Wikimedia Commons itself. In order to keep the metadata up to date on all systems, a tool would be needed to compare, upload and download the metadata from/to Wikimedia Commons.
• Proposed solution: A general GLAM analysis tool that compares the metadata of the GLAM sources with metadata from other sources in Wikimedia Commons. Ideally a solution withOpenRefine or Pattypan. Procedure/Rules: Export metadata from GLAM (xls/csv); Prepare tables for the analysis toolLoad tables in analysis tool; Get/extract Wikimedia Commons Metadata; Compare metadata (i. e. highlighting the differences) and decide; No change -> ignore; Changes by GLAM -> upload the update to WikiCommons via analysis tool; Changes by WikiCommons -> create new csv file for uploading to GLAM.
• Who would benefit: GLAM Institutions on WikiCommons
• More comments: First draft @GLAMhack2021
• Phabricator tickets:
• Proposer: ETH-Bibliothek (talk) 10:32, 21 January 2022 (UTC)

### Discussion

• As Wikipedian working together with different GLAMs I strongly support this proposal. We should try to find methods, how we can make use of the improved metadata where ever they are. (To be transparent: as volunteer I also work together with the ETH-library.) --Hadi (talk) 16:51, 21 January 2022 (UTC)
• Point to Structured Data on Commons: a good addition and a great idea! what i really would appreciate, if such a tool would also point (more) metadata alongside Structured Data on Commons. because structured data contains so much additional knowledge, which could be helpful for updating or reconciling with local data and generally my opinion is that structured data is the bright and sustainable future of metadata in commons. :-) --Mfchris84 (talk) 11:57, 21 January 2022 (UTC)
• Sounds similar to Wikimedia Commons Data Roundtripping and Structured data for GLAM-Wiki/Roundtripping. Jean-Fred (talk) 12:03, 31 January 2022 (UTC)
• What you're describing is multiple copies of the same data being kept in different places and getting out of sync, i.e. data redundancy (the bad kind). A real solution to this problem is to not have the redundancy in the fist place. And if that's not possible for some reason, the process should be much more streamlined than you describe; the server should be able to pull metadata from an alternate source and display it on the page with an easy UI to select the changes to apply. As for exporting, XLS is completely unnecessary since it's a proprietary, convoluted format; CSV offers a minimum of structure, however I would hope systems out there would be capable of reading a semantic structured data export (since Commons already supports structured data). Silver hr (talk) 16:48, 2 February 2022 (UTC)

## Improve LaTeX rendering

• Problem: The current system for displaying mathematical formulas is very unsatisfactory. The formulas are converted into images in which the text appears in black on a transparent background, and then inserted into the text. For this reason, mathematical formulas in some extent clash with the surrounding text:
• Most important : sometimes punctuation signs are rejected on the next line when the formula is at the end of the line (cf. this page, in the second paragraph, or the next one, first line).
• formulas are always black, whatever the color of the surrounding text (see this page, the note);
• the alignment of the mathematical text on the line is not perfect;
• less important, the font differs from the ambient font and does not have exactly the same size.
I would therefore like to see the formulas rendered in a more coherent manner with the surrounding text, and above all in such a way as not to violate the most basic rules of typography.
• Proposed solution: MathJax for example?
• Who would benefit: All readers of scientific articles on Wikipedia/scientific texts on Wikisource or Wikibooks.
• More comments: Please note that the request does not concern the input of mathematics by contributors, but only their display.
• Phabricator tickets:
• Proposer: ElioPrrl (talk) 10:57, 11 January 2022 (UTC)

### Discussion

• We already use mathjax, just rendered to images (Because mathjax is hugely expensive JS to load). —TheDJ (talkcontribs) 10:52, 13 January 2022 (UTC)
So my suggested solution may be discarded, but this does not make the problem (and especially the problem of punctuation) go away. — ElioPrrl (talk) 11:38, 14 January 2022 (UTC)
For the most part, I'm fine with the current SVG rendering, but having at least the option to use others may still be a good implementation. For example, the blog Algorithm Archive uses mathjax as well, and allows changing the rendering very easily (right click the formulas). 83.42.134.97 01:23, 31 January 2022 (UTC)
• It is not true that "formulas are always black": There is a {color} feature. Maybe the description of LaTeX is unsatisfactory.
I mean: the color does not change automatically depending on the ambient text. — ElioPrrl (talk) 18:39, 5 February 2022 (UTC)
• The alignment of the mathematical text can be forced to be perfect. Maybe the description of LaTeX is too complicated and unsatisfactory. -Nomen4Omen (talk) 16:06, 4 February 2022 (UTC)
• I'm not sure if the mismatch between text and formulas is bothersome for many readers: it gives contrast, it may help to skim through. But I think your point was implicitly that gross or slight imperfections jump out even more starkly – to the point of tiring the eye – because of this somewhat strong contrast. Concerning those imperfections:
• The fact that a punctation sign immediately following a formula can go dangling around as the first character on the next line after break is a must fix! The only usable workaround today is to force the punctation in the formula, and since the punctation does not belong to the formula but to the surrounding sentence, it creates a typographic aberration (not to mention the semantic aspect). Maybe the formula processor could simply "eat" punctation signs and put them in a wrapper element with some CSS to prevent line-breaks?
• the same way there is an option <math display=inline>, there could be an option <math color=inherit>, and every wiki could choose its prefered default value?
• the baseline alignment? I guess there is/could be tweaking of configuration of the math renderer at every wiki. I'm certain there is an interaction with the CSS. For example if you paste the same text and formulas between fr.ws and en.ws, you'll see a snappier baseline at en.
• concerning the sizing, if it's not tweakable in the configuration of each wiki, it means every wiki must retrofit its (text) css to match with the math renderer! Trlit (talk) 03:31, 9 February 2022 (UTC)
• Support (didn't know voting ends at 18 UTC): We should start using KaTeX or MathJax already. w:user:Esquivalience/mathjax.js is a good start. ~~~~
18:38, 11 February 2022 (UTC)

## Collection of Commons user images that are used in Wikipedia on an article main page

• Problem: On Wikipedia, many pictures by very arranged "photographers" have been included in main articles of Wikipedia for many years without the "overall effect" of the "commons" photographer on Wikipedia in any way in the "overall volume" quickly becoming apparent to one "foreign" users of this site can be seen. I think not only out of my own interest as a "street photographer" but also for many other "commons photographers" who share our photographic "work" sometimes and increasingly often through "nonsensical USERS" in the world of deletion requests" makes it a little difficult and "restricts" our "life energy" has illustrated.
• Proposed solution: Creation of a tool that shows how many images of the commons photographer are used in Wikipedia main articles. This should also be communicated and displayed to the "deletion initiator" with every image deletion request.
• Who would benefit: Administrators and image deletion applicants can quickly see how active the photographer is on Wiki Commons and Wikipedia. This should also be included more quickly and without "research" by an administrator when making a "deletion decision". In my case, it was precisely this argument that prevented a "USER" from applying for the deletion of my "entire user page" on Wikipedia!
Relieving the administrators by often - deletion and "questionable image deletion requests".

### Discussion

• I've machine-translated your proposal and added the original German as a translation. — SWilson (WMF) (talk) 02:18, 25 January 2022 (UTC)
• If I understand well "Creation of a tool that shows how many images of the commons photographer are used in Wikipedia main articles", GLAMorous could be used here... — Draceane talkcontrib. 21:55, 28 January 2022 (UTC)
• I read the words, but … As a native German with a sufficient performance in understanding English I cannot make any sense of the request, not even parts thereof. It all sounds very metaphysical‽ Where's the German original? Well, I suppose this is a great example illustrating the failure of a deep-learned translation tool in a very specific context! xD --Chrkl (talk) 08:44, 31 January 2022 (UTC)
You can visit Community Wishlist Survey 2022/Multimedia and Commons/Collection of Commons user images that are used in Wikipedia on an article main page/Proposal/de for original verb. Thingofme (talk) 09:59, 1 February 2022 (UTC)
• have you seen the link that Havang(nl) has provided in his opposition vote below? Does that not give you the evidence you need to show how active you (or any other image contributor) have been, and how widely used the image contributions are? --Bobulous (talk) 21:01, 5 February 2022 (UTC)
• Does anyone know how to list unused files uploaded by a certain user? Please ping me, if you know the answer. 4nn1l2 (talk) 17:03, 6 February 2022 (UTC)

## Make the language list accessable

• Problem: At display of a multilingal SVG a drop-down-list ist displayed; this list should be acessible by template or module
• Proposed solution:
• Phabricator tickets:
• Proposer: -- sarang사랑 13:43, 15 January 2022 (UTC)

### Discussion

• @Sarang: This sounds like a useful feature, but could you elaborate a bit more on what the language list data would be useful for? SWilson (WMF) (talk) 14:09, 17 January 2022 (UTC)
• A general addition to the desription page of a multilingual file, to give the user a comfortable overview, is a gallery how the image displays in all the different languages.
This gallery is generated by templates which need a parameter list of the contained languages. Currently this list is independent of the languages that are served in fact - when somebody adds languages but does not maintain the parameter list it will differ. Much better would be when the templates get that list automatically & up-to-time, instead of user-designed; an empty list indicates that no language switch exists.
I am hesitating to write a feature which accesses & analizes the SVG source code: when the tool (unknown to me) which generates the drop-down list of the languages can pass its result somehow to the template, no expensive second access to the source code will be necessary ?
May be that the list can be provided as an expensive LUA title object (a table element) ? But I am open to any other solution. -- sarang사랑 15:58, 17 January 2022 (UTC)
I think exposing this to Lua is a very good implementation idea. Specifically, it should probably be available in the File metadata object. —TheDJ (talkcontribs) 10:48, 19 January 2022 (UTC)
An example gallery at: c:File:Community Wishlist Survey banner - translatable.svg with 12 languages. -- sarang사랑 16:35, 17 January 2022 (UTC)
We have to upload a translation from an external tools, which is not ok. I want to translate it using a MediaWiki tool. Thingofme (talk) 15:55, 18 January 2022 (UTC)
Are you referring to the SVG Translate tool? It's external to the wikis, certainly, but it's definitely a Wikimedia tool (developed by the CommTech team even!). SWilson (WMF) (talk) 03:58, 19 January 2022 (UTC)
@Sarang: That makes sense, thanks. You're right, there should be an easier way to get at this data rather than re-parsing the SVG source. SWilson (WMF) (talk) 03:59, 19 January 2022 (UTC)
• If I understand correctly it would be nice to have a single structured place to save all the available language editions of a multimedia file and be able to query it from wikitext. So, an user can query this list to show a dropdown of this images in the wikitext, as well as a gallery of these images in the wikitext, as well as other things. More generally, it should be possible to answer the question: what other languages does this file support? and get them from wikitext. --Valerio Bozzolan (talk) 16:33, 11 February 2022 (UTC)

## Change interface of FastCCI

• Problem: FastCCI is a brilliant tool when looking for images through categories, but there is a big catch: the preview is cropped to square.
• Proposed solution: Amend FastCCI so that the results are shown in the same manner as normal category pages.
• Who would benefit: Users of FastCCI
• More comments: Having to open every single prospective good image in a new tab is very annoying, so this would be a major improvement. There are other interfaces that can be used, for example the one used for c:Special:MediaSearch: The category one would be the ideal option as it would be possible to use Media Viewer, but that isn't as important as the deployment itself.
• Phabricator tickets:
• Proposer: YTRK (talk) 11:50, 22 January 2022 (UTC)

### Discussion

• Didn't know about this tool, this would be great to modify so that it also satisfies my own proposal. Please make it so that this great tool doesn't crop the results, and displays the filenames. --Enyavar (talk) 10:46, 23 January 2022 (UTC)

## Finish deployment of videojs (and remove kultura)

• Problem: For most of our users (specially logged out ones), the video and audio player is a really old software called kultura, not that it's old and looks ugly but it's also causes slow down of page load due to introduction of a lot of ResourceLoader modules to everyone visiting every page. It is also a lot of code that needs maintenance.
• Proposed solution: There is a replacement called videojs which is even deployed but it's just not enabled for everyone due to some really small bugs here and there. So it's a low hanging fruit.
• Who would benefit: All readers (loading faster), people who load a video or audio (having a better UI), developers (having less code to maintain)
• Phabricator tickets: phab:T248418 (part of phab:T100106)
• Proposer: Amir (talk) 12:14, 15 January 2022 (UTC)

### Discussion

• Yes please ;) —TheDJ (talkcontribs) 15:53, 16 January 2022 (UTC)
• It is 2022 and video functionality is lacklustre. So any little bit - like having a proper player - helps. SSneg (talk) 20:55, 29 January 2022 (UTC)
• Would have supported if I had known voting ended at 18 UTC. ~~~~
18:59, 11 February 2022 (UTC)

## Hover to Zoom of images on desktop

• Problem: Large images such as the Mona Lisa cannot be zoomed into on Desktop without blowing up the whole image - while you can Pinch to Zoom on mobile and easily focus on a specific part of the image, on desktop there's no such option
• Proposed solution: Implement a Hover-to-Zoom feature that can be easily toggled on/off
• Who would benefit: The community
• Phabricator tickets:
• Proposer: TheNewMinistry (talk) 04:27, 11 January 2022 (UTC)

### Discussion

Just tested this on Firefox and Chrome. On desktop you can already easily click to view the full image in a new tab, and from there zoom and pan around to your desire. Not sure what adding a hover-to-zoom function would add, beyond annoyance to people not used to that UX. -- 09:44, 11 January 2022 (UTC)

Indeed. Assuming this were to be implemented, it should be opt-in by default. Amazon has a similar feature on its product pages, and it's incredibly annoying. -FASTILY 02:26, 12 January 2022 (UTC)
It's true that you can load the full-resolution image, but sometimes that's too big for easy browsing. For example, File:Dodekaeder HQ 001 20210703.png. I think the hover to zoom behaviour described here might be something akin to Flickr's system of zooming when hovering (and I guess, only when the media viewer is open, not on every thumbnail). is that right? SWilson (WMF) (talk) 13:54, 17 January 2022 (UTC)
Yeah Flickr's implementation is very good - click once to Zoom 1x and scroll with the mouse cursor, click again to Zoom 2x and scroll with the mouse cursor, click a third time to Zoom back out to original resolution. Would love to see that on Wikipedia. TheNewMinistry (talk) 18:39, 17 January 2022 (UTC)
images [...] cannot be zoomed into on Desktop without blowing up the whole image: The point is specifically to not load the full image. However, I agree with the above comment that ZoomViewer already provides this functionality, though it might be helpful to implement that into MediaWiki. ~~~~
19:06, 11 February 2022 (UTC)

### Voting

•  Support Thingofme (talk) 10:03, 1 February 2022 (UTC)
•  Oppose KingAntenor (talk) 06:51, 2 February 2022 (UTC)
•  Support Uanfala (talk) 21:34, 2 February 2022 (UTC)
•  Support --Ciao • Bestoernesto 17:10, 6 February 2022 (UTC)
•  Oppose per my previous comment -- 11:40, 7 February 2022 (UTC)
•  Support There must always be a link/button that takes you directly to the full-resolution raw image, but I don't think new users would expect to get the full image by clicking on it. Having some sort of 1x/3x Zoom functionality before going up to full res would be helpful, I think. Gaurav (talk) 07:13, 11 February 2022 (UTC)

## Support null edits

• Problem: Categories set or changed by a template won't occur for very long times - or never.
• Proposed solution: Give a possibility to perform null edits for all transclusions of a template
• Who would benefit: all users
• More comments: must not work immediately, just within a reasonable time
• Phabricator tickets:
• Proposer: -- sarang사랑 13:54, 15 January 2022 (UTC)

### Discussion

• Noting for the record that this feature is available when calling the mw:API:Purge endpoint with forcerecursivelinkupdate set to true. Should be possible to wrap in a userscript. -FASTILY 00:18, 16 January 2022 (UTC)
In my experience, forcerecursivelinkupdate will update the appearance of transcluded templates, but not categories added by templates. For that, an actual null edit on transcluding pages is required. I use en:User:Ahecht/Scripts/refresh to accomplish that. -- Ahecht (TALK
PAGE
) 17:15, 24 January 2022 (UTC)
forcerecursivelinkupdate is supposed to update the categories, as the categorylinks are part of the "link update" its name refers to. If it's not, that's a bug. Anomie (talk) 23:47, 28 January 2022 (UTC)
There is also w:user:Frietjes/masspurge.js. ~~~~
18:27, 11 February 2022 (UTC)
• Categories set or changed by a template won't occur for very long times - or never. What about finding a fix for this instead? I'd wish it, too. --Matěj Suchánek (talk) 09:08, 16 January 2022 (UTC)
• Kind of wondering why this is in Multimedia and Commons. This impacts every use of categories. --Izno (talk) 06:29, 18 January 2022 (UTC)
Agreed. * Pppery * it has begun 18:49, 28 January 2022 (UTC)
• I thought this was done by default when a template is updated? Otherwise, it is quite simple to write a pywikibot script that goes through template uses and null edits it - but that's not good for the servers if it's already being done. Thanks. Mike Peel (talk) 18:32, 28 January 2022 (UTC)
This does happen eventually for some templates, but the system is imperfect and pages get missed sometimes. For example, I ran a null edit script to clear w:Category:CS1 maint: discouraged parameter in October 2021, when the category still had ~20,000 pages despite the code to populate it having been removed in May. * Pppery * it has begun 18:49, 28 January 2022 (UTC)
• Or someone could fix task T132467 or task T157670. Null edits to every page are needed periodically, and my understanding is that the technical implementation of it is not difficult. Someone just needs to make it happen. Jonesey95 (talk) 22:26, 28 January 2022 (UTC)
• I imagine another suitable solution here for the problem described would just be to have changes occour faster once templates are changed. ·addshore· talk to me! 22:49, 4 February 2022 (UTC)

### Voting

•  Support * Pppery * it has begun 18:49, 28 January 2022 (UTC)
•  Oppose I do not want, that null edits will fill file or category histories. Taivo (talk) 19:53, 28 January 2022 (UTC)
Null edits do not show up in page histories or watchlists. Jonesey95 (talk) 22:30, 28 January 2022 (UTC)
Exactly as Jonesey95 said. NULL edits are invisible. Valerio Bozzolan (talk) 14:58, 11 February 2022 (UTC)
•  Support one way or another. It is probably easiest to implement one of the fixes described in the phab tickets linked above. Jonesey95 (talk) 22:30, 28 January 2022 (UTC)
•  Support The best implementation isn't clear, but please provide something better than making a JWB list and clicking Save on dummy edits. Certes (talk) 01:32, 29 January 2022 (UTC)
•  Support Libcub (talk) 22:53, 30 January 2022 (UTC)
•  Support We need to purge this page often for technical reasons. Thingofme (talk) 09:56, 1 February 2022 (UTC)
•  Oppose KingAntenor (talk) 06:49, 2 February 2022 (UTC)
•  Support Ayumu Ozaki (talk) 09:55, 6 February 2022 (UTC)
•  Support --Ciao • Bestoernesto 17:07, 6 February 2022 (UTC)
•  Support Valerio Bozzolan (talk) 14:57, 11 February 2022 (UTC)

• Problem: No Mass uploaders like Vicuna, Pattypan are functional for months, and the problems are not being addressed seriously even though links to the same are shown at the main page under Upload.
• Proposed solution: Please revive or patch or repair the issue with Pattypan, they may not be big issues to rectify. The Foundation may have to fund a bit to take back it to working at the earliest. It seems that the people who should address the issue are not serious enough to make it right.
• Who would benefit: All media uploaders who want to share their hard gained images and media for the world for free, without ever giving to non-free platforms.
• Phabricator tickets: phab:T293543
• Proposer: Vinayaraj (talk) 03:01, 12 January 2022 (UTC)

### Discussion

• I found this GitHub issue for Pattypan and another issue for Vicuna. Are these the issues you refer to? Is there anything else we should know? Also, and this may be a dumb question, but is there anything against a web-based mass uploader? Thanks, MusikAnimal (WMF) (talk) 04:24, 12 January 2022 (UTC)
Yes, that is the issue.--Vinayaraj (talk) 14:59, 12 January 2022 (UTC)
A web-based mass uploader that can process spreadsheets like Pattypan does would certainly be nice, but for the time being, I would like to see Pattypan fixed as fast as possible, because there are stuck ongoing GLAM projects that rely on it, and then think about future tools (see also my comment below). Gestumblindi (talk) 14:43, 15 January 2022 (UTC)
A web-based mass uploader is not nice. The webpage will be killed or unresponsive if you load a number of images(which are very easy on pattypan or vicuna). Just try the UploadWizard with a 50 or some images then you can directly experience the issue. If we can develop a much more stable mass uploader then that will be good. --Ranjithsiji (talk) 05:49, 20 January 2022 (UTC)
• Support for the requirements of an available mass uploader, e.g. for media in general. Before implementing a new uploader it might make sense to look at possible problems at the API. May be the proposal addresses a backend problem, that blocks upload clients to work as espected - e.g. that the upload clients like Commonist, Pattypan, Vicuna, ... cannot upload files due to backend modification of the API must be blocked due to a specific cause or challenge. --Bert Niehaus (talk) 10:09, 12 January 2022 (UTC)
• I fear that putting this on a "Wishlist" implies it's just something that's nice to have or that the community would like. Bulk uploads are a central part of the partnerships Wikimedia has built up with galleries, libraries, archives, museums and other partner organisations. Often those partner organisations and the relevant Wikimedia chapter have put funding and staff time into those relationships, and had difficult conversations to persuade those partners to adopt free licensing. When bulk uploads are put on hold because the suitable tools aren't working, that halts the work of those partnerships, undermining the paid staff and the work done to build the partnership. The more months the situation goes on, the more damage is done and the less impact funders are seeing for their money. To a crucial part of the Wikimedia movement, this is a critical problem requiring an urgent fix, not something we'd like to have eventually. MartinPoulter (talk) 12:37, 12 January 2022 (UTC)
• For context Pattypan has uploaded more that 1.1 million images to Commons, without tools like this available all my mass upload projects are on hold indefinately and partners may loose interest, same for everyone else. MusikAnimal (WMF) I have more background info on why PattyPan etc are broken if helpful. John Cummings (talk) 12:43, 12 January 2022 (UTC)
• Its kind of disconcerting that no one has been able to fix these apps apparently. The fix is relatively simple. If no one was able to deliver these fixes, are the apps even viable at all long term any longer ? —TheDJ (talkcontribs) 12:57, 12 January 2022 (UTC)
• I know several GLAMs who used Pattypan and now have problems with mass uploads since months. This is a very important issue from my point of view. --Hadi (talk) 15:02, 12 January 2022 (UTC)
• This is a crisis. We need a tool for batch uploading. As of now we have a half-functioning patch that works only in Ubuntu and that I have to operate on behalf of various other Czech Wikipedians. The global GLAM seems to be paralyzed to a great degree as large amount of people simply have no way how to upload large groups of images. There are GLAM users who try to virtualize Ubuntu to be able to send images to Wikimedia Commons. 🤦‍♂️ There is only one volunteer in the Github project who simply does not have resources to fix the issue, despite a huge amount of work he did. Github shows questions from various people from all around the world asking "when the thing will start working"? This should be a priority issue and should be fixed fast. Aktron (talk) 17:40, 12 January 2022 (UTC)
• I never liked Pattypan and Vicuna, and I hate the built-in uploader with all my heart, so please please please make something simple and really usable like Commonist work again. The Commons are dead without it. --Anvilaquarius (talk) 08:59, 13 January 2022 (UTC)
• @Vinayaraj @Vysotsky I agree with the longing for Pattypan above, thanks Vinayaraj for sounding the alarm.
While the classic UploadWizard continues to work for small numbers of images, a Mediawiki software change should not stall excellent tools as Pattypan for more substantial uploads with varied metadata, which for instance Commonist cannot handle. (The cumbersome but very effective GlamWikiToolset is out of business as well by the change in Mediawiki software?)
At the African Studies Center of Leiden University we rely on Pattypan for a Master thesis project by a student and for longer term projects of thousands of photos by the local Wikimedian in residence, supervised by the librarian.
So please repair Pattypan! thank you, Hansmuller (talk) 14:13, 13 January 2022 (UTC) Wikimedian in residence ASC Leiden
• The root cause of this is that a MediaWiki change broke my bot framework, which all three of these tools use a legacy version of. This was fixed three months ago but cannot be easily backported - I rewrote that part of the code to use the new HTTP client in Java 11 some time ago. The solution is to port all three tools to Java 11 (and 17) so that they can use the latest version. MER-C 20:37, 13 January 2022 (UTC)
• There is an experimental version of Pattypan (21.10-experimental-2, "This package migrates Pattypan to Java 11+, OpenJFX, and mainstream Wiki.java.") that apparently works, but only under Linux. Using Windows, the login step seems to work, but the actual upload fails with a "GOAWAY" message from the server. As this is a tool that is widely in use by GLAMs and they are accustomed to its workflow (and often use only Windows), if it's fairly easy to fix, which I would assume it should be, it would be a better approach to first fix Pattypan fully, so that people can continue with their projects in the way they're familiar with, and then think about possible other tools. See also the discussion from here and in the sections below that. In my opinion, a quick fix that just makes the familiar Pattypan working again for now is more important than more time-consuming additional ideas/projects. Gestumblindi (talk) 12:28, 15 January 2022 (UTC)
• Curious if you're familiar with the work currently being done to build a new structured data/batch uploading tool for Commons that leverages the OpenRefine data cleaning/manipulation software – does this address what you're looking for? MPinchuk (WMF) (talk) 20:17, 17 January 2022 (UTC)
I have no technical know-how about these things. I have been using Pattypan for long and it is exactly what I needed, missing it heavily. Vinayaraj (talk) 13:19, 18 January 2022 (UTC)
I am leading the development of the OpenRefine batch upload functionality. In my experience, people can learn to use OpenRefine in one or two hours. We'll do our best to organize trainings and create good documentation. Spinster (talk) 09:23, 23 January 2022 (UTC)
Thank you, looking forward to the release Vinayaraj (talk) 15:22, 23 January 2022 (UTC)
• I think it's a very important issue for mass uploading files in Commons; and I thinks licensing of the files are the problems. Thingofme (talk) 15:47, 18 January 2022 (UTC)
• Please bring back Pattypan for Windows users! I work for Dumbarton Oaks and we have an established workflow that was functional with Pattypan but has been stalled out for months now. You cannot underestimate the lead time that it takes institutions like ours which don't have Wikimedians in residence to be able to start a process like this, and having that process stymied is causing us to lose a lot of momentum. I recognize that we owe a great debt of gratitude to the people who have the knowhow to build these tools, especially when they are doing it on their own free time, so I am not putting this on them, but if there is anything the Wikimedia Foundation can do to help, institutions like mine would be extremely grateful. Bettinche (talk) 03:33, 19 January 2022 (UTC)
• Just adding my support to fix the issues with Pattypan, specifically the issues with the Windows version as a minimum. This is identified as the current problem on the GitHub page. For libraries looking to upload large collections with their metadata, it does seem the best tool out there. I also found it useful for mapping our metadata schema to Wikimedia's. I would certainly be interested in the proposal to have Wikimedia Commons functions in OpenRefine mentioned by , as I do use OpenRefine a lot for cleaning metadata records. However, I think in the short-term fixing the issues with Pattypan may be more achievable. --Wjbfarrell (talk) 11:51, 19 January 2022 (UTC)
• I agree that it's imperative to fix Pattypan, even if it's just implementing a stop-gap measure. GLAMs rely on it, and there's no equivalent tool out there. The OpenRefine Commons upload sounds interesting, but it's not expected to be operational until June 2022 at the earliest. In the meantime, this bottleneck is going to be frustrating for many, especially because Pattypan wasn't deprecated or phased out, it just stopped working. brwz (talk) 16:20, 19 January 2022 (UTC)
Yes; GLAMs should be able to at least finish their current Pattypan-based upload projects that are now suddenly stuck in the midst of their established workflow. Then, certainly, if there are some even better tools someday, a phase out date for Pattypan could be announced, so that everyone has enough time to adapt, but people need a working Pattypan first. Gestumblindi (talk) 23:53, 19 January 2022 (UTC)
• Also the Image Archive of the ETH-Library is very hugely depending on the functionality and functioning of Pattypan! We are planning to upload more than 100'000 Swissair areal images and other. We used to work with GWToolset but as it was communicated that this tool is no longer being maintained, we changed our whole workflow to work with Pattypan and also helped other GLAM-institutions to get used with it. We would be very greatful if the tool would work again soon! ^FH ETH-Bibliothek (talk) 07:24, 20 January 2022 (UTC)
• The Central Library of Zurich is planning to load more image collections up to Wikimedia Commons, currently a collection of ~2'000 images, and more collections in the future. For doing this, we really depend on Pattypan. If it could run again on Windows, that would be a big plus. ^AW --Zentralbibliothek Zürich (talk) 13:08, 20 January 2022 (UTC)
• I also ask for the resolution of the problem. The project I am following has stopped uploading images for over 3 months due to the Pattypan malfunction. --Spinoziano (BEIC) (talk) 09:16, 22 January 2022 (UTC)
• Bring back Pattypan soon. I support Vinayaraj. There is no substitute for Pattypan. UploadWizard has its own demerits. Moreover mass unloading should be promoted. Shagil Kannur (talk) 09:39, 23 January 2022 (UTC)
• Chipping in on this in support for restoring Pattypan a.s.a.p. while we wait for OpenRefine to take over. We in the Netherlands also have several GLAM institutions that are affected by this. MichellevL (WMNL) (talk) 09:32, 26 January 2022 (UTC)
• Info: 4 days ago, a new experimental Pattypan release (pattypan-21-10-experimental-3) was made by Abbe98 and I can happily report that it does work under Windows 10! We're currently uploading images using that release. You still need to manually install and load OpenJFX modules (starting Pattypan from commandline with the options as in the example), but it does work. . Zentralbibliothek Solothurn (talk) 15:19, 27 January 2022 (UTC)
Unfortunately, there are still some issues with pattypan-21-10-experimental-3 and pattypan-21-10-experimental-4 - in my case, the test load gets stuck at the first image, as reported here: Issue #145. ^AW --Zentralbibliothek Zürich (talk) 16:06, 31 January 2022 (UTC)
Well, we just uploaded a batch of 192 files with experimental-4 and the upload never got stuck in the way it did previously. There was a "Connection reset" error message after 119 images and the next image was skipped, but that was after I left the machine unattended for a while and then the upload continued successfully without the need to restart Pattypan, so I think that's a different issue. Zentralbibliothek Solothurn (talk) 18:10, 2 February 2022 (UTC)
• Some time after Vicuna, Commonist and Pattypan stopped working, Vicuna 1.24.8a portable appeared, which does work for me, albeit partially. It has three bugs: 1) (random) often one or more files do not get uploaded wihtou obvious reason, 2) (random) it forgets the previously entered coordinates and one has to scroll across the globe to get again to a specific location, 3) (persistent) no category checking. If these issues are fixed, I think many users will be happy. JiriMatejicek (talk) 09:03, 1 February 2022 (UTC)
• I fixed (1). The latest experimental versions of Pattypan and Vicuna should have this fix incorporated. MER-C 18:25, 3 February 2022 (UTC)
• Pattypan version 22.02 is now available. You can find the download and the release notes here. Abbe98 (talk) 15:41, 7 February 2022 (UTC)
• Just a link to our project report regarding VicuñaUploader improvement. --Juandev (talk) 04:12, 7 May 2022 (UTC)

## Easy edit tool for EXIF data

• Problem: If you want to edit EXIF data (eg. correcting the date, adding a EXIF information for description, author, licence, GPS etc.) you have to reupload the entire file.
• Proposed solution: Some edit tool that allows you to edit the EXIF info directly via the webpage like a text editor. It would also be a good idea if the tool had some options like exiftool to correct your date in a very easy way.
• Who would benefit: People who upload a file to Commons and want to edit the EXIF data
• More comments: So that the EXIF data can not just not destroyed by some user, the edits can be limited to the uploader of a file or a specialised group of users.

As far as I know, there is an option to add custom EXIF fields to an image. If there would be an easy solution to add and edit EXIF data this could add up to an option for adding a new field to include eg. Wikidata item(s)

• Phabricator tickets:
• Proposer: --D-Kuru (talk) 14:01, 18 January 2022 (UTC)

### Discussion

• This is partly intentional. EXIF is considered to be 'non-editable' and original part of our files. Even if we save an upload and download, from a user perspective, there would still have to be an entire new copy of the file in the file history. Any corrections to this should generally be made to the file description page or the Structured data area. —TheDJ (talkcontribs) 15:41, 19 January 2022 (UTC)
• There should be at least possibility to delete/edit coordinates from exif. When somebody makes photo of something at home with mobile, but wants nobody to know his home coords. Or. I once made a photo of wayside shrine, but my phone had still my home coordinates and photo was placed on map 100 km away from real position - on my home. JAn Dudík (talk) 10:03, 20 January 2022 (UTC)
Frankly, I think an option to strip geotagging should be part of the image upload flow along with a map showing where it thinks the image was taken. There have been too many times that I've uploaded an image with the embedded coordinates for my house, which meant I had to strip the EXIF, re-upload, and then contact an admin to revdel the earlier versions. -- Ahecht (TALK
PAGE
) 17:32, 24 January 2022 (UTC)
See also phab:T218057, phab:T222675, and phab:T22326. Jean-Fred (talk) 12:18, 31 January 2022 (UTC)
• Embedded metadata is often lost when editing a file. (Finding a good tool for) Copying it over from an older or different file can be difficult for many people. Therefore, when overwriting a file, an option to copy over metadata from the/an older version would be great. but this should maybe rather happen on upload when a file is about to be overwritten, combined with an appropriate check for removed metadata, and perhaps rather not as a separate editing option. Visualization of changes to metadata on upload would be useful.--Reseletti (talk) 16:37, 5 February 2022 (UTC)

## Commons Categories for Discussion tools

• Problem: It's a lot of manual work to close category discussions at Commons:Categories for discussion. After closing the discussion and likely taking some action (manually deleting or moving a category), the closing admin needs to manually remove the notification tag (Commons:Template:Category for discussion) from the category page and manually link the discussion on the talk page of the discussion page. Each month, new headers need to be manually added to a new CfD page, and the Commons:Template:CFD month header needs to be manually updated. Note that this is not a small amount of work, because there are an almost uncountable number of open discussions at Commons:Categories for discussion (dating back to 2015) that will need to be closed.
• Proposed solution: Some combination of bot and tools that can help with the manual efforts described above.
• Who would benefit: Admins would benefit from saved labour. Users would benefit because CfDs would likely be closed at least a little sooner.
• Phabricator tickets:
• Proposer: Themightyquill (talk) 13:15, 11 January 2022 (UTC)

### Discussion

Does c:Help:Gadget-DelReqHandler already do this? If not, maybe it could be extended include this functionality. -FASTILY 07:06, 14 January 2022 (UTC)

@Fastily, I think the tool is c:user:BMacZero/AjaxCfdClose.js. I don't think we need to include a project-specific feature into a MW extension, especially if the functionality already exists. ~~~~
18:56, 11 February 2022 (UTC)

### Voting

• Problem: Uploading a single PDF page image as a standalone image is too time consuming
• Proposed solution: A tool that will upload a PDF preview image from Commons with relevant metadata, as a Commons image file, to save having to download it locally and re-upload it, and having to manually enter the metadata entry?
• Who would benefit: Anyone wishing to add an image of a single page from a PDF to a project.
• Phabricator tickets:
• Proposer: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:11, 15 January 2022 (UTC)

### Discussion

• I'm not sure I follow. You mean, in order to use just one page as an image? Can't the page=x parameter be used for that, e.g.: [[File:Ettelaat13420926.pdf|page=1|200px]]

Sorry if I'm missing the obvious! :-) SWilson (WMF) (talk) 14:20, 17 January 2022 (UTC)
• I wasn't aware of that (it's a neat trick, thank you), so I doubt most re-users are. But how can that parameter be passed to, say, the crop tool? Or the image downloaded at full resolution? Or individually categorised? Or used as an image in Wikidata? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:36, 17 January 2022 (UTC)
Good points! The crop tool already supports cropping images from within pages in PDFs, e.g.. For downloading full-res single-page images, the thumbnail links under the image on Commons work, but it seems that links such as [[Media:Ettelaat13420926.pdf|page=1]] do not (and I can't find a phab task for that). To individually categorize a single page, it will as you say have to be uploaded as a separate file, but perhaps the crop tool is the easiest way to do that — often a crop or other modification would be wanted anyway, I think. The same applies for Wikidata images. SWilson (WMF) (talk) 06:47, 18 January 2022 (UTC)
BTW. page= is described/documented in Wikipedia:Extended_image_syntax and Help:Images. But I do agree that discoverability could be improved, and for instance sometime like the VisualEditor does not support this image option, which is genuinely a shame. I have created phab:T301161 to request adding this as a feature. —TheDJ (talkcontribs) 17:41, 7 February 2022 (UTC)
[[File:Ettelaat13420926.pdf|page=1|200px]] Works for wiki, but how to store this page in Wikidata image (P18) ? JAn Dudík (talk) 07:05, 19 January 2022 (UTC)
it's hard for doing that. We can use this as a property for page number, but... Thingofme (talk) 12:35, 19 January 2022 (UTC)
@JAn Dudík and Thingofme: Yes, it'll need to be uploaded as a separate file. That's why I'm wondering if the crop tool workaround is sufficient for this use case, because that tool already handles copying over the metadata etc. and it's just a matter of cropping to the full page. But anyway, I'll mark this for translation and it can proceed to voting (after the 28th). SWilson (WMF) (talk) 06:33, 20 January 2022 (UTC)
You can try to add a page number as a qualifier (using page(s) (P304)), but (1) Wikidata doesn't know how to show you the image for the selected page(s), and (2) this triggers a validation error, since P304 is not expected to be a qualifier for image (P18). Gaurav (talk) 07:08, 11 February 2022 (UTC)

## Cross-referencing Utility for Films

• Problem: Users often access Wikipedia articles about films to look up actors and other personnel and see what other films these people have worked on. Though IMDb.com offers a comparable database, at present no utility exists for cross-referencing personnel.
• Proposed solution: The proposed utility would allow two or more names to be input into a search, the result of which would show films that contained those personnel. The data afforded by this utility could otherwise only be accessed through painstaking manual crossreferencing.
• Who would benefit: Researchers who study films in which specific combinations of personnel appear, including actors who appear together but also less likely but potentially significant combinations like a certain actor and cinematographer. Fans who are curious to have an insider perspective on the behind-the-scenes world of film personnel.
• Phabricator tickets:
• Proposer: TeiseiMG (talk) 17:22, 18 January 2022‎ (UTC)

### Discussion

• This seems like it could be done with a Wikidata query today. --Izno (talk) 19:45, 18 January 2022 (UTC)
• I agree with Izno. This sounds like a special case of a more general need to have a user-friendly browsing/query interface for Wikidata. Silver hr (talk) 18:26, 2 February 2022 (UTC)

## Improve browsing PDFs and DJVU

• Problem: Currently PDFs which are uploaded like this one have a very rudimentary paging interface, which is only available on the file description page. The interface does a full page reload and is not very usable on mobile interfaces. Also when transcluded, you can only select 1 page, and from there you cannot reach any other page, you have to click and visit the File description page.
• Proposed solution: I propose enhancing the view with a JS based left/right arrow interface and loading pages on demand and to make the interface mobile compatible.
• Who would benefit: Users trying to interact with our paged media, curators, especially on Mobile
• More comments: To improve performance, we could preload the next and previous pages. Possibly extend this UI to also allow to be opened in the MediaViewer software when the PDF is embedded in a wikipage.
• Phabricator tickets: Slightly related: phab:T54881
• Proposer: —TheDJ (talkcontribs) 16:05, 16 January 2022 (UTC)

### Discussion

• This is a nice wish. PDF generation (from articles) and PDF visualization (from files in Commons) is an urgent pending task since long ago. Xavier Dengra (MESSAGES) 23:59, 21 January 2022 (UTC)

## Improve SVG rendering

• Problem: SVG images are currently rendered as scalar images before being displayed in Wikipedia articles, because at the time SVG support was added, many browsers could not reliably display SVGs. That rendering is currently being done by librsvg 2.40.x, which was deprecated in 2017, and which causes compatibility issues with lots of modern SVG images. Upgrading to a newer version has been blocked by the fact that the Thumbor thumbnailing system has no maintainer and is still running on Debian Stretch, despite the Wikimedia operating system upgrade policy saying that Stretch should've been phased out by June 2021, and Debian marking Stretch as End of life in June of 2022. An effort to replace librsvg altogether has stalled due to lack of WMF developer support for Thumbor.
• Proposed solution: Proposed solution is threefold:
• Find a maintainer for Thumbor and upgrade it to a modern operating system (likely Bullseye at this point, since Buster deprecation is supposed to begin later this year)
• Evaluate and implement a new SVG renderer
• Since all modern browsers have robust SVG support, allow SVGs to be displayed directly without conversion to scaler images under certain circumstances (the SVG is smaller in file size than the equivalent raster thumbnail, the SVG does not contain <text></text> tags since that can create issues with installed fonts and the systemLanguage attribute, etc.)
• Who would benefit: Anyone that creates SVG images, adds SVG images to articles, or reads articles that would benefit from better SVG rendering.
• Phabricator tickets: phab:T5593, phab:T40010, phab:T193352, phab:T216815, phab:T247697, phab:T294484.
• Proposer: Ahecht (TALK
PAGE
) 21:31, 10 January 2022 (UTC)

### Discussion

• I agree with this 100%, and whether or not this proposal is accepted now, it is going to have to be done at some near point down the line, and the sooner it is worked on the sooner we can get the headache out of the way. When it comes to librsvg, there have been several times when I have created or uploaded SVG images (for example, the logo for Post Luxembourg on enwiki) and either the old version of librsvg has rendered it completely incorrectly compared to how my browser does natively (also a point in favor of allowing direct displaying of SVG images, as pretty much all modern browsers have support for that) or renders it with graphical errors (see also SVG_help#Common_problems on enwiki), meaning that I (or another editor) then needs to find out where the error is, what is causing it, and develop a workaround, which ends up taking much more time and (often) results in a larger file size. I also wonder if there are certain scenarios where a higher-quality SVG image could currently be use, but the editor who wanted to make the change at the time is dissuaded from continuing due to an error which this far down the line (involving both a renderer nearly a decade out of date, a deprecated operating system, and a continuing lack of WMF support) should not need to be dealt with. HapHaxion (talk) 20:34, 11 January 2022 (UTC)
• Removed phab:T43426, phab:T64987 from the list of tickets, both get fixed with updating the software.--Snævar (talk) 18:47, 13 January 2022 (UTC)
• Showing SVGs natively on browsers allows to use animated SVG images (SMIL) for illustrations, icons, etc. which is definitely superior to GIF format in terms of quality, modifiability and size.Example 1, Example 2, Example 3 Jooja (talk) 10:32, 17 January 2022 (UTC)
• I agree that native svg rendering by browsers has a lot of advantages compared to librsvg but there may be some downsides. I work on maps in svg format which are much bigger in file size than the equivalent png format. As example this map is 14 MB in svg while it is 4.5 MB in 2000x4000px in png. --Ikonact (talk) 14:27, 30 January 2022 (UTC)
• I take it it's too early (in terms of current web browser support) to use the picture element with the SVG file within a source element, and a fallback JPEG file within an img element, as described nicely on this page? --Bobulous (talk) 20:07, 5 February 2022 (UTC)

## Make category browsing multilingual using Wikidata

• Problem: Although Commons is a multilingual project, MediaWiki categories can only have a label in one language. Wikidata changes this: when a category is linked to Wikidata (which over 3 million of them now are), you can define labels for it on Wikidata in many languages. The Wikidata Infobox displays those multilingual labels within the category, so you can see the topic info in your language when you are within the category. However, subcategories only appear in the language they were created in (normally English), which can make it difficult for people that don't know that language to browse them.
• Proposed solution: Use the Commons <-> Wikidata sitelinks to Wikidata to display a category label in the user's requested language. This would be best done within MediaWiki itself rather than having Javascript or similar trying to rewrite the labels after rendering.
• Who would benefit: Commons editors and readers who do not know English
• More comments: A bonus would be if image (P18) could also be used to show subcategory thumbnails, and perhaps also use the descriptions on hover-over to add additional context. This was previously proposed in the 2021 wishlist, along with a related proposal for multilingual category names
• Phabricator tickets: N/A
• Proposer: Mike Peel (talk) 20:44, 15 January 2022 (UTC)

### Voting

•  Support --Crazy1880 (talk) 19:52, 28 January 2022 (UTC)
•  Support 4nn1l2 (talk) 19:57, 28 January 2022 (UTC)
•  Support --Arnd (talk) 19:58, 28 January 2022 (UTC)
•  Support Rzzor (talk) 20:00, 28 January 2022 (UTC)
•  Support Christian Ferrer (talk) 20:09, 28 January 2022 (UTC)
•  Support Jmmuguerza (talk) 20:31, 28 January 2022 (UTC)
•  Support USI2020 (talk) 20:42, 28 January 2022 (UTC)
•  Support Triplec85 (talk) 21:50, 28 January 2022 (UTC)
•  Support Vis M (talk) 20:51, 28 January 2022 (UTC)
•  Support Strainu (talk) 21:23, 28 January 2022 (UTC)
•  Support — Draceane talkcontrib. 21:59, 28 January 2022 (UTC)
•  Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:58, 29 January 2022 (UTC)
•  Support Betseg (talk) 02:19, 29 January 2022 (UTC)
•  Support --Higa4 (talk) 05:41, 29 January 2022 (UTC)
•  Support Ottawajin (talk) 06:17, 29 January 2022 (UTC)
•  Support Steven Sun (talk) 07:27, 29 January 2022 (UTC)
•  Support Till.niermann (talk) 09:44, 29 January 2022 (UTC)
•  Support As a part of a larger goal of making our "multilingual" projects actually multilingual. They're unilingually English now and that problem needs to be solved. Meiræ 11:27, 29 January 2022 (UTC)
•  Support Aca (talk) 14:53, 29 January 2022 (UTC)
•  Support Mbrickn (talk) 16:16, 29 January 2022 (UTC)
•  Oppose @Mike Peel This proposal would involve creating Wikidata items for every single Commons category. What should happen instead is Commons categories get their own structured data per-category. This works just like how Files on Commons have their own structured data. Files have their own structured data and not Wikidata items for good reason: Wikidata is meant to store data about the universe, not every little thing about Wikimedia. Wikimedia projects should aim to store data about themselves as much as possible, just as Structured data across Wikimedia is planning to do with Wikipedia. Additionally, this would be better than using Wikidata because Commons editors could translate categories from Commons itself and would not have to create a Wikidata item and navigate to Wikidata. Lectrician1 (talk) 20:22, 29 January 2022 (UTC)
• Except none of that exists, and this is a solution that would work now? Thanks. Mike Peel (talk) 20:23, 29 January 2022 (UTC)
Your proposal requires work as well. We have also already set up page-based structured data on Commons before so it shouldn't be hard to extend that to Categories and having the translations Commons-based is a plus. I'm just asking that we evaluate what solution will work best for editors and Commons in the long-run. Lectrician1 (talk) 20:29, 29 January 2022 (UTC)
•  Support JAn Dudík (talk) 23:18, 29 January 2022 (UTC)
•  Support only if it does not mean creating WD item for every Commons category. Wostr (talk) 23:54, 29 January 2022 (UTC)
I can't imagine it would ... something like, say, "Stone houses in London" could be keyed to those three WD items. Daniel Case (talk) 23:24, 1 February 2022 (UTC)
@Daniel Case How is that supposed to work? This would require MediaWiki to correctly inflect virtually all nouns and know which case to use with which preposition, which I doubt is in any way close to being implemented. ~~~~
19:03, 11 February 2022 (UTC)
•  Support OwenBlacker (Talk) 10:49, 30 January 2022 (UTC)
•  Support F. Riedelio (talk) 11:08, 30 January 2022 (UTC)
•  Support --Luan (discussão) 22:47, 30 January 2022 (UTC)
•  Support Libcub (talk) 22:55, 30 January 2022 (UTC)
•  Support Ariadacapo (talk) 10:14, 31 January 2022 (UTC)
•  Support β16 - (talk) 10:58, 31 January 2022 (UTC)
•  Support NaBUru38 (talk) 13:19, 31 January 2022 (UTC)
•  Support Daud Iffa (talk) 13:52, 31 January 2022 (UTC)
•  Support Thingofme (talk) 09:56, 1 February 2022 (UTC)
•  Support Daniel Case (talk) 23:23, 1 February 2022 (UTC)
•  Support Very necessary. Serg!o (talk) 11:14, 2 February 2022 (UTC)
•  Support Geert Van Pamel (WMBE) (talk) 13:58, 2 February 2022 (UTC)
•  Oppose per Lectrician1. Silver hr (talk) 17:53, 2 February 2022 (UTC)
•  Support Giacomo Alessandroni let's talk! 14:38, 3 February 2022 (UTC)
•  Support Paucabot (talk) 15:36, 3 February 2022 (UTC)
•  Support Syced (talk) 10:31, 4 February 2022 (UTC)
•  Support per Meiræ. — Bilorv (talk) 20:45, 4 February 2022 (UTC)
•  Oppose If it is not guaranteed that it will not interfere with Commons categories linking to Wikipedia articles. If this could lead to a drive towards forcing linking Commons categories to Wikipedia categories, something quite disrupting to who does categorization on Commons, then Strong oppose. - Darwin Ahoy! 21:10, 4 February 2022 (UTC)
• @DarwIn: That's a long-solved problem through the inclusion of the Wikidata Infobox in the category, which links to articles over categories where the articles exist. Thanks. Mike Peel (talk) 08:39, 5 February 2022 (UTC)
@Mike Peel no, its. not. It was only partially patched to try to circumvent the disruptive connections that have imposed from Wikidata, forcing Commons categories to be linked to the (mostly useless for Commons) Wikipedia categories, while Wikipedia article mainspace is still linked to the Commons gallery namespace, which was never designed for that. Bringing even more stuff to work over that broken framework only worsens the situation. Just no. - Darwin Ahoy! 13:51, 5 February 2022 (UTC)