Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Multimedia and Commons

< Community Wishlist Survey 2022
Community Wishlist Survey 2022
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.

  • Proposed solution: Upgrade the Vega library, add Vega-Lite support, and add multilingual support to Graphs.

    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)[reply]

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)[reply]

    @MusikAnimal (WMF): 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)[reply]
  • 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)[reply]
    @Snævar: This might be a good separate proposal. —TheDJ (talk • contribs) 15:51, 16 January 2022 (UTC)[reply]

Voting

Upload assistant: coordinates picker

  • 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)[reply]

Discussion

Voting

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.
  • More comments:
  • Phabricator tickets:
  • Proposer: CdnMCG (talk) 20:56, 21 January 2022 (UTC)[reply]

Discussion

I agree. One new tool should be able to achieve both proposals. CdnMCG (talk) 00:48, 28 January 2022 (UTC)[reply]
  • 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)[reply]
    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)[reply]

Voting

WikiCommons metadata analysis tool

  • 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)[reply]

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)[reply]
  • 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)[reply]
  • Sounds similar to Wikimedia Commons Data Roundtripping and Structured data for GLAM-Wiki/Roundtripping. Jean-Fred (talk) 12:03, 31 January 2022 (UTC)[reply]
  • 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)[reply]

Voting

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)[reply]

Discussion

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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. ~~~~
    User:1234qwer1234qwer4 (talk)     18:38, 11 February 2022 (UTC)[reply]

Voting

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

Voting

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:
  • Who would benefit: automatic actualized galleries; no own-written second access to read the source code
  • More comments:
  • Phabricator tickets:
  • Proposer: -- sarang♥사랑 13:43, 15 January 2022 (UTC)[reply]

Discussion

  • 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)[reply]
I think exposing this to Lua is a very good implementation idea. Specifically, it should probably be available in the File metadata object. —TheDJ (talk • contribs) 10:48, 19 January 2022 (UTC)[reply]
@SWilson (WMF): An example gallery at: c:File:Community Wishlist Survey banner - translatable.svg with 12 languages. -- sarang♥사랑 16:35, 17 January 2022 (UTC)[reply]
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)[reply]
@Thingofme: 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)[reply]
@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)[reply]
  • 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)[reply]

Voting

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)[reply]

Discussion

Voting

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)
  • More comments:
  • Phabricator tickets: phab:T248418 (part of phab:T100106)
  • Proposer: Amir (talk) 12:14, 15 January 2022 (UTC)[reply]

Discussion

Voting

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
  • More comments:
  • Phabricator tickets:
  • Proposer: TheNewMinistry (talk) 04:27, 11 January 2022 (UTC)[reply]

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. --//Lollipoplollipoplollipop::talk 09:44, 11 January 2022 (UTC)[reply]

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)[reply]
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). @TheNewMinistry: is that right? SWilson (WMF) (talk) 13:54, 17 January 2022 (UTC)[reply]
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)[reply]
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. ~~~~
User:1234qwer1234qwer4 (talk) 19:06, 11 February 2022 (UTC)[reply]

Voting

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)[reply]

Discussion

Voting

Mass uploader

  • 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.
  • More comments: See also:
  • Phabricator tickets: phab:T293543
  • Proposer: Vinayaraj (talk) 03:01, 12 January 2022 (UTC)[reply]

Discussion

Yes, that is the issue.--Vinayaraj (talk) 14:59, 12 January 2022 (UTC)[reply]
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)[reply]
@Gestumblindi: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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 (talk • contribs) 12:57, 12 January 2022 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • @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[reply]
  • 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)[reply]
  • 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)[reply]
  • Everyday uploading of media to various places like, Facebook, Instagram or say Google photos are becoming very easier. For any commoner it is more than sufficient to keep their memories to themselves or share with the world. Not many are bothered about the license. But for those who insist to upload to Wikimedia Commons, they have a special aim: to share their media forever, to anyone seek knowledge from anywhere, anytime without the slightest of limitations or login. These are the class of people who do not want any profit or mention. And these are the very people find it most difficult to upload their photos. It is the duty of the foundation to rectify the existing glitches of uploading, a day sooner so that this class of people will not go away. Sincerely desire to see Pattypan back into action at the earliest.--Vinayaraj (talk) 13:50, 15 January 2022 (UTC)[reply]
  • @Vinayaraj: 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)[reply]
    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)[reply]
    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)[reply]
    Thank you, looking forward to the release Vinayaraj (talk) 15:22, 23 January 2022 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 @MPinchuk (WMF):, 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. @Vinayaraj, MusikAnimal (WMF), Hadi, Aktron, Hansmuller, ETH-Bibliothek, Zentralbibliothek Zürich, Spinoziano (BEIC), and MichellevL (WMNL):. Zentralbibliothek Solothurn (talk) 15:19, 27 January 2022 (UTC)[reply]
    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)[reply]
    @Zentralbibliothek Zürich and Abbe98: 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Just a link to our project report regarding VicuñaUploader improvement. --Juandev (talk) 04:12, 7 May 2022 (UTC)[reply]

Voting

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)[reply]

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 (talk • contribs) 15:41, 19 January 2022 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    See also phab:T218057, phab:T222675, and phab:T22326. Jean-Fred (talk) 12:18, 31 January 2022 (UTC)[reply]
  • Thanks, D-Kuru! I was going to propose something similar, but missed the deadline. So I've had some prior thoughts about how this could work. (1) Allow to strip but not write certain fields (especially privacy-sensitive ones) and not others; (2) Allow strip &/or modify on upload only, but not afterward (as per Ahecht); (3) Allow modify at any time but only by the original uploader. Re. "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," I've been in exactly that situation before, and I'm sure many others have too. Good EXIF editing software is hard to find, especially on mobile devices. I suspect we have a lot of people revealing PII from mobile and not even knowing it. GPS co-ords, makernotes, author, copyright holder, and maybe camera serial number come to mind as being potentially sensitive. I might want to have my real-life name configured in my camera for day-to-day shots, but not accidentally doxx myself on-wiki. If author and copyright were writable, I could embed "© Pelagic on Wikimedia Commons, CC-BY-SA" to encourage proper attribution by downloaders/re-users. A nice enhancement would be to pull the info into the image description & structured data before stripping it from the file, or a button to do so next to the delete button. Another nice-to-have: option to round the geo co-ords to the nearest a° b′ or a few decimal places, to allow approximate location without pinpointing a specific house. ⁓Pelagic (talk) 03:36, 28 January 2022 (UTC)[reply]
  • 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)[reply]

Voting

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.
  • More comments: Please and thank you.
  • Phabricator tickets:
  • Proposer: Themightyquill (talk) 13:15, 11 January 2022 (UTC)[reply]

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)[reply]

@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. ~~~~
User:1234qwer1234qwer4 (talk) 18:56, 11 February 2022 (UTC)[reply]

Voting

PDF preview image upload

  • 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.
  • More comments: Example images
  • Phabricator tickets:
  • Proposer: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:11, 15 January 2022 (UTC)[reply]

Discussion

Voting

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.
  • More comments:
  • Phabricator tickets:
  • Proposer: TeiseiMG (talk) 17:22, 18 January 2022 (UTC)[reply]

Discussion

Voting

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 (talk • contribs) 16:05, 16 January 2022 (UTC)[reply]

Discussion

Voting

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.
  • More comments:
  • Phabricator tickets: phab:T5593, phab:T40010, phab:T193352, phab:T216815, phab:T247697, phab:T294484.
  • Proposer: Ahecht (TALK
    PAGE    ) 21:31, 10 January 2022 (UTC)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]

Voting

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)[reply]

Discussion

Voting

Wikimedia Commons: New setting for description language for new uploads

  • Problem: The default language of the website UI can be set. The default website UI language is used for descriptions when a new image is uploaded with UploadWizard. So you can either change your whole interface language or change the language for every upload.
  • Proposed solution: New setting for a default language value
  • Who would benefit: People who write descriptions in languages other than their interface
  • More comments: With that change you can use the interface in your language (eg. japanese) and do not have to switch the language for every new upload when you want to add an english description. An alternative option would be to have a list of your last used languages.

    The main point is: You have to change the language for *every* description (for every file twice if you add a short description) and you may have to search for the language if it's not listed at the very top.

  • Phabricator tickets:
  • Proposer: Hangman'sDeath (talk) 11:31, 18 January 2022 (UTC)[reply]

Discussion

@TheDJ: I expanded the description and added more information.
The Special:Upload dialog is even worse for mobile users. You have to enter everything manually and you can only upload one file at a time. I'm talking about using the UploadWizard on a smartphone browser. In the fourth tab (first tab being the one that tells you if you are allowed to upload the file to Commons) you can add a description to the file. For this description you can change the language. By default it takes the UI language set in your preferences. If you are using the UI in eg. Japanese and want to contribute english descriptions you have to change the language for every description. Hangman'sDeath (talk) 08:13, 20 January 2022 (UTC)[reply]

  • e.g. so you would like to have the website always in Arabic as default, but always having the default inputs taking Italian as default. Is it correct? If yes, is this more a problem on bulk uploads, or during a single upload? --Valerio Bozzolan (talk) 15:03, 11 February 2022 (UTC)[reply]

Voting

World map extension

  • Problem: World maps are a useful means to provide a quick overview in many articles. However, a minority of users are skilled to create and update such maps.
     
    Example of a map that regularly needs to be updated (plastic bag laws)
  • Proposed solution: It would be handy to have an extension (similar to e.g. Graph or EasyTimeline) for world maps. It would need be possible to assign a color to each country (using codes such as USA or ITA).
  • Who would benefit: Users who don't have SVG editing skills; readers who are shown world maps (that would otherwise not exist).
  • More comments: It would make it easier and quicker to create and updated such maps compared to editing SVG files. Examples of the types of maps that could be created and updated using such an extension are found in e.g. Category:SVG political maps of the world.
  • Phabricator tickets:
  • Proposer: Leyo (talk) 01:16, 19 January 2022 (UTC)[reply]

Discussion

  1. allow upload of css files associated to svg maps. This may be not very convenient but is still easier to update a text file with a country ISO code. A graphical tool to change these codes may help. I proposed this solution previously with the aim to reduce the size of maps as the svg picture of the borders is the same for all maps and only colors change.
  2. create a graphical tool as proposed earlier by SWilson. I agree with Leyo that the SVG Map Maker tool is not the most convenient. I worked on a similar tool here. that allows to adapt any map from Commons and update it. I still work on it but I tried with few maps and it works quite fine. The only condition is to adapt slightly the svg maps by adding a specific class name to the elements representing shapes of countries to be colored.
I will be glad to help on this request. --Ikonact (talk) 20:37, 20 January 2022 (UTC)[reply]
By the way the tool I created can provide more than just coloring countries but also some basic pie charts, waffle charts or bubble charts. Otherwise this tool in Wikipedia may be used to color code countries on map. --Ikonact (talk) 21:07, 20 January 2022 (UTC)[reply]
Thank you. I wasn't aware of Template:Graph:Map. This is nearly what I was proposing. It has, however, one major drawback: As opposed to an image, there does not seem to be a possibility to add a thumb version of it to an article, whereas the full version is only shown when clicked on. --Leyo (talk) 22:59, 20 January 2022 (UTC)[reply]
  • I very much recognize this need, I've been trying to push for it inside WMF for a while. Two pieces of context might help. Graphoid was recently decomissioned and there's a stalled effort to bring it back online. This would allow us to render thumbnails to fix the problem @Leyo mentions above. On a parallel track, there's hope that the visualization components we built for Wikistats 2 will be upstreamed to Wikimedia Codex, the new standard design system that we'll use for UI going forward. I just hope we can connect one or both of those efforts to this very real need. Milimetric (WMF) (talk) 13:40, 3 February 2022 (UTC)[reply]
  • Would have supported if I had known voting ended at 18 UTC. ~~~~
    User:1234qwer1234qwer4 (talk)     19:17, 11 February 2022 (UTC)[reply]

Voting

Allow UploadWizard to use other templates for import (Book, Artwork, etc.)

  • Problem: Now, when importing a book or an artwork, you need to complete a standard Information template, THEN go to the imported file and change it to the template you really need
  • Proposed solution: have a choice to import with a menu on Description tab : use specific templates (Book, Artwork, Art Photo, maybe others, I do not know)
  • Who would benefit: all people who import artworks or books manually (not power importers)
  • More comments: It would be to allow another description template than basic "Information"...
when uploading book scans, using Book would be appreciated... -> now, you have to import it with Information, THEN convert the template to Book, and then to complete the template with other data...
same with Artwork, and other similar templates...
it would be great also, using Book, Artwork or Art Photo, to be allowed to import simply refering to a wikidata item for description, describing the artwork or book edition... -> only would need to add Source - all data would be there...

Discussion

Would have supported if I had known voting ended at 18 UTC. ~~~~
User:1234qwer1234qwer4 (talk) 18:57, 11 February 2022 (UTC)[reply]

Voting

Map of user's uploads

  • Problem: It is often difficult (especially for someone who has uploaded a lot of files) to remember if you have already uploaded a file that represents a certain place. A user accessible map to check (based on the file coordinates) which images have been uploaded would be very useful to the whole project.
  • Proposed solution: Create a map (similar to the one on Flickr) showing the uploaded photos and the coordinates they represent.
  • Who would benefit: The users and the project
  • More comments:
  • Phabricator tickets:
  • Proposer: Mannivu · ✉ 13:42, 17 January 2022 (UTC)[reply]

Discussion

Voting

Annotations in panoramic images

  • Problem: Some panorama images can only be viewed in full resolution, e.g. here. So far, annotations can only be made in the preview on the image description page. That doesn't help here.
  • Proposed solution: As with this page, informative captions should be easily inserted into the full resolution of an image that the viewer can turn on or off.
  • Who would benefit: All images, where informations should be switched on or off in full resolution.
  • More comments:
  • Phabricator tickets:
  • Proposer: Milseburg (talk) 15:08, 21 January 2022 (UTC)[reply]

Discussion

  • @Milseburg: Thanks for your proposal! Am I reading this correctly that you're proposing that the large full-page image viewer should support annotations? Does phab:T58666 cover what you're proposing? Also, is "Annotations in panoramic images" a reasonable English translation of the above title? (We'll rename the page, and it'll be translated back to German.) — SWilson (WMF) (talk) 02:11, 24 January 2022 (UTC)[reply]
Yes I think, the tranlation is ok. I noticed to late, that I wrote the title in German and don't know how to move it. Unfortunately, I can't quite follow the discussion on phabT58666, but if you could switch annotations on and off in the original resolution, that would make sense for all images. The prerequisite is that this labeling can be inserted in a user-friendly manner. A viewer like this would be the crowning glory. --Milseburg (talk) 18:43, 24 January 2022 (UTC)[reply]
@Milseburg: Okay great. And yes, the details may still need to be figured out, but this sounds like a solid proposal. I'll set it up for translation now. SWilson (WMF) (talk) 00:07, 25 January 2022 (UTC)[reply]

Voting

Allow import of Flickr images regardless of claimed licence

  • Problem: Trusted users cannot import PD images from Flickr, if they are set to a non-free licence
  • Proposed solution: Allow trusted users (however defined and flagged) to import Flickr images regardless of claimed licence
  • Who would benefit: Experienced Commons uploaders; end users
  • More comments: A user can use the Upload Wizard to upload images from Flickr, if they have a free licence, or are marked as PD. They can upload images which have a non-free licence on Flickr, by first downloading them from Flickr to their hard drive, if they can make a case that they are PD (e.g. scans of old ephemera, 2D images of PD paintings)). They should be able to do this without the intermediate step.
  • Phabricator tickets: phab:T281599
  • Proposer: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:59, 15 January 2022 (UTC)[reply]

Discussion

Voting

  • Problem: For referencing audio files inline, such as pronunciation demonstrations, wikis have relied on linking to the raw file using [[Media:...]], via templates like {{audio}}. But not all browsers support playing the linked file (which can be Ogg Vorbis, WAV, FLAC, WebM, Opus, or MIDI), causing them to download the file instead of playing it, even though audio files are now automatically transcoded into Ogg and MP3 specifically so that browsers can play them. And even when the browser supports it, this is not user-friendly as it suddenly sends them to a different page with nothing but a player on it.
  • Proposed solution: Create a parser extension tag like <audio file="Example.ogg">Link</audio> which fetches the derivative URLs and then converts to e.g. <a href="/wiki/File:Example.ogg" title="Example.ogg" data-audiolink="[{"src":"//upload.wikimedia.org/wikipedia/commons/c/c8/Example.ogg","type":"audio/ogg"},{"src":"//upload.wikimedia.org/wikipedia/commons/transcoded/c/c8/Example.ogg/Example.ogg.mp3","type":"audio/mpeg"}]">Link</a> and attach a handler that converts the JSON data to an HTMLAudioElement and plays it to the link's click event.
  • Who would benefit: Readers
  • More comments:
  • Phabricator tickets: T229169
  • Proposer: Nardog (talk) 07:37, 21 January 2022 (UTC)[reply]

Discussion

Voting

Enable chunked uploads for files that replace existing files

  • Problem: The direct upload of a file that is intended to replace another file always times out for large files because the direct upload mecanism does not chunk the file. The Upload Wizard is not configured to allow the uploader to designate the file as a replacement for an existing file.
  • Proposed solution: Allow chunking in direct upload or add replacement of existing file as an option in Upload Wizard.
  • Who would benefit: All uploaders of large replacement images. Easier replacement of dirty or damaged images.
  • More comments:
  • Phabricator tickets:
  • Proposer: Downtowngal (talk) 15:09, 22 January 2022 (UTC)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2022/Multimedia_and_Commons&oldid=22829020"