Community Wishlist Survey 2022/Multimedia and Commons
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)
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)
- @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)
- 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 (talk • contribs) 15:51, 16 January 2022 (UTC)
Voting
- Support Vis M (talk) 20:54, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 21:58, 28 January 2022 (UTC)
- Support Izno (talk) 23:47, 28 January 2022 (UTC)
- Support Aca (talk) 14:54, 29 January 2022 (UTC)
- Support Piensaimnieks (talk) 15:17, 29 January 2022 (UTC)
- Support Libcub (talk) 23:00, 30 January 2022 (UTC)
- Support JPxG (talk) 00:54, 31 January 2022 (UTC)
- Support NaBUru38 (talk) 13:18, 31 January 2022 (UTC)
- Support Nw520 (talk) 18:31, 31 January 2022 (UTC)
- Support Thingofme (talk) 09:54, 1 February 2022 (UTC)
- Support Uanfala (talk) 21:27, 2 February 2022 (UTC)
- Support Nousername46000 (talk) 00:35, 4 February 2022 (UTC)
- Support this should be done by further developing the visualization of commons tabular data. Tomastvivlaren (talk) 09:22, 5 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:11, 6 February 2022 (UTC)
- Support DALIBRI (talk) 09:14, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 09:38, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:56, 6 February 2022 (UTC)
- Support 4nn1l2 (talk) 17:16, 6 February 2022 (UTC)
- Support Bkn anime (talk) 18:15, 6 February 2022 (UTC)
- Support Tom Ja (talk) 17:41, 7 February 2022 (UTC)
- Support There is even so much low hanging fruit here, that could be easily solved. I don't even want big things, just some solid improvmeents. —TheDJ (talk • contribs) 17:44, 7 February 2022 (UTC)
- Support — DaxServer (t · c) 20:15, 8 February 2022 (UTC)
- Support Mihai Capotă (talk) 06:50, 10 February 2022 (UTC)
- Support Marcok (talk) 07:54, 10 February 2022 (UTC)
- Support Quiddity (talk) 08:33, 10 February 2022 (UTC)
- Support Yair rand (talk) 07:20, 11 February 2022 (UTC)
- Support Valerio Bozzolan (talk) 14:55, 11 February 2022 (UTC)
- Support Forrestkirby (talk) 15:32, 11 February 2022 (UTC)
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)
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)
Voting
- Support --Nachtbold (talk) 18:41, 28 January 2022 (UTC)
- Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:39, 28 January 2022 (UTC)
- Support --Arnd (talk) 19:59, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 21:56, 28 January 2022 (UTC)
- Support Lion-hearted85 (talk) 22:41, 28 January 2022 (UTC)
- Support JopkeB (talk) 06:29, 29 January 2022 (UTC)
- Support ··· 🌸 Rachmat04 · ☕ 08:16, 29 January 2022 (UTC)
- Support Šedý (talk) 10:56, 29 January 2022 (UTC)
- Support Piensaimnieks (talk) 15:13, 29 January 2022 (UTC)
- Support rubin16 (talk) 16:02, 29 January 2022 (UTC)
- Support Ali Imran Awan (talk) 07:16, 30 January 2022 (UTC)
- Support Nw520 (talk) 22:34, 30 January 2022 (UTC)
- Support Libcub (talk) 22:50, 30 January 2022 (UTC)
- Support JPxG (talk) 00:52, 31 January 2022 (UTC)
- Support Ariadacapo (talk) 10:17, 31 January 2022 (UTC)
- Support Hb2007 (talk) 14:24, 31 January 2022 (UTC)
- Support Havang(nl) (talk) 16:29, 31 January 2022 (UTC)
- Support JRennocks (talk) 17:06, 31 January 2022 (UTC)
- Support !!! JAn Dudík (talk) 21:07, 31 January 2022 (UTC)
- Support Thingofme (talk) 09:56, 1 February 2022 (UTC)
- Support Daniel Case (talk) 23:26, 1 February 2022 (UTC)
- Support Nosferattus (talk) 02:34, 2 February 2022 (UTC)
- Support The Android Commons app has this feature. Syced (talk) 10:33, 4 February 2022 (UTC)
- Support Gwyndon (talk) 11:44, 4 February 2022 (UTC)
- Support kocio ✉ 01:02, 6 February 2022 (UTC)
- Support--Vulp❯❯❯here! 07:38, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:10, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 09:40, 6 February 2022 (UTC)
- Support Redalert2fan (talk) 14:45, 6 February 2022 (UTC)
- Support 4nn1l2 (talk) 15:20, 6 February 2022 (UTC)
- Support paul2520 (talk) 16:43, 7 February 2022 (UTC)
- Support But i do think that a coordinate picker is useless, without a good name based search. Picking a coordinate by hand is just too cumbersome for most. —TheDJ (talk • contribs) 17:31, 7 February 2022 (UTC)
- Support — DaxServer (t · c) 20:06, 8 February 2022 (UTC)
- Support Marcok (talk) 08:06, 10 February 2022 (UTC)
- Support Sunpriat (talk) 02:03, 11 February 2022 (UTC)
- Support Yep for the already-existing c:Tempalte:Location of the photographer but it would be nice to add support to c:Template:Object location too since both are a pain and always inserted using tools like https://locator-tool.toolforge.org/ . --Valerio Bozzolan (talk) 14:50, 11 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.
- More comments:
- Phabricator tickets:
- Proposer: CdnMCG (talk) 20:56, 21 January 2022 (UTC)
Discussion
- Related to Community Wishlist Survey 2022/Multimedia and Commons/Enable chunked uploads for files that replace existing files I believe. --Izno (talk) 03:41, 23 January 2022 (UTC)
- 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
- Support Libcub (talk) 22:47, 30 January 2022 (UTC)
- Support An improvement to VisualFileChange. Thingofme (talk) 10:02, 1 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:11, 6 February 2022 (UTC)
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)
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)
Voting
- Support —The Editor's Apprentice (talk) 18:57, 28 January 2022 (UTC)
- Support Hadi (talk) 18:10, 29 January 2022 (UTC)
- Support Nicole Graf (talk) 07:16, 31 January 2022 (UTC)
- Support Sentenzius (talk) 08:12, 31 January 2022 (UTC)
- Support — The preceding unsigned comment was added by Rjl724 (talk) 08:33, 31 January 2022 (UTC)
- Support Kleiner T-Rex (talk) 13:36, 31 January 2022 (UTC)
- Support FluraFlu (talk) 15:29, 31 January 2022 (UTC)
- Support SBB Historic (talk) 17:04, 31 January 2022 (UTC)
- Support Carla Jung (talk) 08:02, 1 February 2022 (UTC)
- Support Mianga (talk) 08:02, 1 February 2022 (UTC)
- Support FJohner64 (talk) 09:46, 1 February 2022 (UTC)
- Support Thingofme (talk) 10:06, 1 February 2022 (UTC)
- Support Little-creator (talk) 10:48, 1 February 2022 (UTC)
- Support Swiss National Library (talk) 11:22, 1 February 2022 (UTC)
- Support Si. Leitner (talk) 12:51, 1 February 2022 (UTC)
- Support Julihi (talk) 07:26, 2 February 2022 (UTC)
- Support El ribi (talk) 08:24, 2 February 2022 (UTC)
- Support HHeike (talk) 14:54, 2 February 2022 (UTC)
- Support HouseBlaster (talk) 01:09, 3 February 2022 (UTC)
- Support Hedger z Castleton (talk) 15:54, 4 February 2022 (UTC)
- Support Poacea (talk) 15:32, 5 February 2022 (UTC)
- Support--Vulp❯❯❯here! 07:38, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:10, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 09:41, 6 February 2022 (UTC)
- Support paul2520 (talk) 16:57, 7 February 2022 (UTC)
- Support Tom Ja (talk) 17:45, 7 February 2022 (UTC)
- Support Talmoryair (talk) 09:36, 8 February 2022 (UTC)
- Support Marcok (talk) 07:51, 10 February 2022 (UTC)
- Support AnanasL (talk) 07:55, 10 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 (talk • contribs) 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. ~~~~
User:1234qwer1234qwer4 (talk) 18:38, 11 February 2022 (UTC)
Voting
- Support --Raymonde Lanthier (talk) 14:13, 29 January 2022 (UTC)
- Support --F0x1 (talk) 14:35, 29 January 2022 (UTC)
- Support TheInternetGnome (talk) 08:14, 30 January 2022 (UTC)
- Support Alan Talk 13:36, 30 January 2022 (UTC)
- Support Thingofme (talk) 09:51, 1 February 2022 (UTC)
- Support KingAntenor (talk) 06:49, 2 February 2022 (UTC)
- Support Uanfala (talk) 21:31, 2 February 2022 (UTC)
- Support kocio ✉ 01:06, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:42, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 09:32, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:09, 6 February 2022 (UTC)
- Support No to dangling punctuations after line breaks! Trlit (talk) 03:38, 9 February 2022 (UTC)
- Support —— TheodoreIndiana (talk) 06:29, 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".
- More comments:
- Phabricator tickets:
- Proposer: Lupus in Saxonia (talk) 15:13, 11 January 2022 (UTC)
Discussion
- @Lupus in Saxonia: 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)
- @Lupus in Saxonia: 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)
Voting
- Support Piensaimnieks (talk) 15:11, 29 January 2022 (UTC)
- Support Mbrickn (talk) 16:14, 29 January 2022 (UTC)
- Oppose @Lupus in Saxonia: Here is your list [1] Glamorous is this tool. --Havang(nl) (talk) 16:56, 31 January 2022 (UTC)
- Thank you, @Havang(nl). I had no idea there was a way to see a list of WikiMedia articles/pages which are using photos I've uploaded. That GLAMorous report generator is great. Bobulous (talk) 20:57, 5 February 2022 (UTC)
- Support I think we need the tools Thingofme (talk) 10:00, 1 February 2022 (UTC)
- Support I think we need the tools --Lupus in Saxonia (talk) 15:07, 1 February 2022 (UTC)
- Oppose KingAntenor (talk) 06:53, 2 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:08, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:56, 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:
- 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)
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 (talk • contribs) 10:48, 19 January 2022 (UTC)
- @SWilson (WMF): 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)
- @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)
- @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)
- 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)
- 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)
Voting
- Support Lectrician1 (talk) 02:03, 29 January 2022 (UTC)
- Support Images that are translations of the images are ok. Thingofme (talk) 10:06, 1 February 2022 (UTC)
- Support Daniel Case (talk) 23:22, 1 February 2022 (UTC)
- Support 4nn1l2 (talk) 07:41, 4 February 2022 (UTC)
- Support Mrmw (talk) 08:03, 5 February 2022 (UTC)
- Support — Johannes Kalliauer - Talk | Contributions 08:11, 5 February 2022 (UTC)
- Support kocio ✉ 01:16, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:05, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:00, 6 February 2022 (UTC)
- Support —TheDJ (talk • contribs) 17:34, 7 February 2022 (UTC)
- Support Nice to have if I understand correctly (comment in discussion) Valerio Bozzolan (talk) 16:34, 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)
Voting
- Support Thingofme (talk) 10:03, 1 February 2022 (UTC)
- Support Why not. Valerio Bozzolan (talk) 14:59, 11 February 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)
- More comments:
- Phabricator tickets: phab:T248418 (part of phab:T100106)
- Proposer: Amir (talk) 12:14, 15 January 2022 (UTC)
Discussion
- Yes please ;) —TheDJ (talk • contribs) 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. ~~~~
User:1234qwer1234qwer4 (talk) 18:59, 11 February 2022 (UTC)
Voting
- Support USI2020 (talk) 20:45, 28 January 2022 (UTC)
- Support Izno (talk) 23:45, 28 January 2022 (UTC)
- Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 02:00, 29 January 2022 (UTC)
- Support Heavily needed. Lectrician1 (talk) 02:04, 29 January 2022 (UTC)
- Support Lt2818 (talk) 06:44, 29 January 2022 (UTC)
- Support Mbrickn (talk) 16:17, 29 January 2022 (UTC)
- Support Please! --SSneg (talk) 20:53, 29 January 2022 (UTC)
- Support Tgr (talk) 00:14, 30 January 2022 (UTC)
- Support Hb2007 (talk) 14:25, 31 January 2022 (UTC)
- Support the wub "?!" 14:30, 31 January 2022 (UTC)
- Support Yes, we need to change! Thingofme (talk) 10:01, 1 February 2022 (UTC)
- Support Daniel Case (talk) 23:18, 1 February 2022 (UTC)
- Support Please. Nosferattus (talk) 02:40, 2 February 2022 (UTC)
- Support Serg!o (talk) 11:16, 2 February 2022 (UTC)
- Support Lol78231469 (talk) 14:08, 4 February 2022 (UTC)
- Support —Thanks for the fish! talk•contrib (he/him) 21:48, 5 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:39, 6 February 2022 (UTC)
- Support DALIBRI (talk) 09:13, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 09:37, 6 February 2022 (UTC)
- Support paul2520 (talk) 16:58, 7 February 2022 (UTC)
- Support (and i have good hope that we will be able to do this soon) —TheDJ (talk • contribs) 17:49, 7 February 2022 (UTC)
- Support · · · Peter (Southwood) (talk): 13:49, 9 February 2022 (UTC)
- Support Quiddity (talk) 08:37, 10 February 2022 (UTC)
- Support Spinster (talk) 11:34, 10 February 2022 (UTC)
- Support Yair rand (talk) 07:20, 11 February 2022 (UTC)
- Support — putnik 15:03, 11 February 2022 (UTC)
- Support stjn[ru] 16:50, 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
- More comments:
- 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. --//Lollipoplollipoplollipop::talk 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). @TheNewMinistry: 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)
- Something like what commons:Help:Gadget-ZoomViewer? Jean-Fred (talk) 12:06, 31 January 2022 (UTC)
- This sounds like it should be a browser feature. Silver hr (talk) 16:53, 2 February 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. ~~~~
User:1234qwer1234qwer4 (talk) 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 --//Lollipoplollipoplollipop::talk 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. ~~~~
User:1234qwer1234qwer4 (talk) 18:27, 11 February 2022 (UTC)
- In my experience,
- 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)
- 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)
- Null edits do not show up in page histories or watchlists. Jonesey95 (talk) 22:30, 28 January 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)
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)
Discussion
- @Vinayaraj: 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)
- @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)
- 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 (talk • contribs) 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)
- 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)
- @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)
- 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 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)
- 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 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 @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)
- 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. @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)
- 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)
- @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)
- 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)
- 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)
Voting
- Support Important issue to fix. Thanks. Mike Peel (talk) 18:31, 28 January 2022 (UTC)
- Support * Pppery * it has begun 18:48, 28 January 2022 (UTC)
- Support --Nachtbold (talk) 18:52, 28 January 2022 (UTC)
- Support We need stable batch editing tools. Wskent (talk) 19:17, 28 January 2022 (UTC)
- Support Vis M (talk) 20:53, 28 January 2022 (UTC)
- Support Jmmuguerza (talk) 21:44, 28 January 2022 (UTC)
- Support!!! — Draceane talkcontrib. 21:58, 28 January 2022 (UTC)
- Support Aktron (talk) 22:19, 28 January 2022 (UTC)
- Support Sea Cow (talk) 23:11, 28 January 2022 (UTC)
- Support Izno (talk) 23:45, 28 January 2022 (UTC)
- Support ··· 🌸 Rachmat04 · ☕ 08:17, 29 January 2022 (UTC)
- Support--Manojk (talk) 13:03, 29 January 2022 (UTC)
- Support -Vijayanrajapuram (talk) 14:02, 29 January 2022 (UTC)
- Support Aca (talk) 14:45, 29 January 2022 (UTC)
- Support --Shagil Kannur (talk) 14:52, 29 January 2022 (UTC)
- Support --Ajeeshkumar4u (talk) 14:53, 29 January 2022 (UTC)
- Support -Adarshjchandran (talk) 15:13, 29 January 2022 (UTC)
- Support Piensaimnieks (talk) 15:18, 29 January 2022 (UTC)
- Support rubin16 (talk) 16:05, 29 January 2022 (UTC)
- Support --Denis Gagne52 (talk) 17:25, 29 January 2022 (UTC)
- Support--Sugeesh (talk) 17:56, 29 January 2022 (UTC)
- Support----Irvin calicut (talk) 18:05, 29 January 2022 (UTC)
- Support--Fuad (talk)Fuadaj (talk) 18:09, 29 January 2022 (UTC)
- Support Hadi (talk) 18:11, 29 January 2022 (UTC)
- Support -- Rajeshodayanchal (talk) 01:45, 30 January 2022 (UTC)
- Support OwenBlacker (Talk) 10:48, 30 January 2022 (UTC)
- Support Sreejithkoiloth (talk) 17:23, 30 January 2022 (UTC)
- Support Coffeeandcrumbs (talk) 20:10, 30 January 2022 (UTC)
- Support Libcub (talk) 22:46, 30 January 2022 (UTC)
- Support JPxG (talk) 00:50, 31 January 2022 (UTC)
- Support so many projects are broken without a working mass uploader John Cummings (talk) 08:49, 31 January 2022 (UTC)
- Support Trizek from FR 13:42, 31 January 2022 (UTC)
- Support the wub "?!" 14:30, 31 January 2022 (UTC)
- Support brwz (talk) 14:34, 31 January 2022 (UTC)
- Support Anvilaquarius (talk) 14:45, 31 January 2022 (UTC)
- Support Sadads (talk) 15:51, 31 January 2022 (UTC)
- Support Mass uploader oke, but demands quite some discipline of the uploader : there is need for correct filenaming / description / categories before uploading, not after uploading. Years after uploading, numerous mass uploaded files have insufficient names, are still not correctly renamed and stay insufficiently categorised. Havang(nl) (talk) 16:40, 31 January 2022 (UTC)
- Support MONUMENTA (talk) 00:52, 1 February 2022 (UTC)
- Support JiriMatejicek (talk) 09:09, 1 February 2022 (UTC)
- Support Thingofme (talk) 10:02, 1 February 2022 (UTC)
- Support Pharos (talk) 01:46, 2 February 2022 (UTC)
- Support Geert Van Pamel (WMBE) (talk) 13:55, 2 February 2022 (UTC)
- Support Bluerasberry (talk) 17:05, 2 February 2022 (UTC)
- Support VIGNERON * discut. 17:51, 2 February 2022 (UTC)
- Support Ɱ (talk) 03:30, 3 February 2022 (UTC)
- Support EN-Jungwon 10:32, 3 February 2022 (UTC)
- Support Layka100 (talk) 11:15, 3 February 2022 (UTC)
- Support Paucabot (talk) 15:39, 3 February 2022 (UTC)
- Support 4nn1l2 (talk) 07:42, 4 February 2022 (UTC)
- Support. Need it.-- MASUM THE GREAT (talk) 11:22, 4 February 2022 (UTC)
- Support Rzuwig► 12:27, 4 February 2022 (UTC)
- Support, though it shouldn't take the Wishlist to get this fixed. It's a collection of bugs that other WMF teams should be putting much concerted effort towards fixing. Nonetheless, it seems they aren't. — Bilorv (talk) 20:42, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 00:25, 5 February 2022 (UTC)
- Support – KPFC 💬 11:14, 5 February 2022 (UTC)
- Support SD hehua (talk) 15:20, 5 February 2022 (UTC)
- Support Lutzto (talk) 17:28, 5 February 2022 (UTC)
- Support Like Mike Peel --Packa (talk) 23:09, 5 February 2022 (UTC)
- Support--Vulp❯❯❯here! 07:37, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:09, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 09:43, 6 February 2022 (UTC)
- Oppose --Ciao • Bestoernesto • ✉ 17:03, 6 February 2022 (UTC)
- Support Fiver, der Hellseher (talk) 19:59, 6 February 2022 (UTC)
- Support paul2520 (talk) 16:45, 7 February 2022 (UTC)
- Oppose issues have been resolved with Pattypan 22.02. MER-C 18:03, 7 February 2022 (UTC)
- No, I installed the latest Java updates ver 22.02 is still showing errors 117.213.87.159 13:50, 8 February 2022 (UTC)
- Would you mind sharing those issues? Users have successfully uploaded over 10 000 images since the release. Abbe98 (talk) 18:32, 11 February 2022 (UTC)
- I think this was the problem with invalid titles not being handled gracefully. I fixed one of the NPEs they cause today but it needs further work (now if you call getPageInfo it will return null for invalid titles). Maybe Pattypan/Vicuna should not assume that my code is bug free and at least print a stack trace of atypical exceptions. MER-C 20:19, 11 February 2022 (UTC)
- It did not have any such problems in the past. Any non-techie could upload images with a few clicks. After installing 22.02, the error is-
- Error:A JNI error has occurred, please check your installation and try again. Vinayaraj (talk) 14:06, 13 February 2022 (UTC)
- I think this was the problem with invalid titles not being handled gracefully. I fixed one of the NPEs they cause today but it needs further work (now if you call getPageInfo it will return null for invalid titles). Maybe Pattypan/Vicuna should not assume that my code is bug free and at least print a stack trace of atypical exceptions. MER-C 20:19, 11 February 2022 (UTC)
- Would you mind sharing those issues? Users have successfully uploaded over 10 000 images since the release. Abbe98 (talk) 18:32, 11 February 2022 (UTC)
- No, I installed the latest Java updates ver 22.02 is still showing errors 117.213.87.159 13:50, 8 February 2022 (UTC)
- Support ~Cybularny Speak? 21:14, 7 February 2022 (UTC)
- Support — DaxServer (t · c) 20:12, 8 February 2022 (UTC)
- Support BugWarp (talk) 00:11, 9 February 2022 (UTC)
- Support · · · Peter (Southwood) (talk): 13:41, 9 February 2022 (UTC)
- Support Marcok (talk) 07:48, 10 February 2022 (UTC)
- Support Desmedth (talk) 13:46, 10 February 2022 (UTC)
- Support Hillun Vilayl Napis (WMID) (talk) 12:17, 11 February 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 (talk • contribs) 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)
- 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
- 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)
- 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)
Voting
- Support Piensaimnieks (talk) 15:12, 29 January 2022 (UTC)
- Support Pelagic (talk) 23:03, 29 January 2022 (UTC)
- Support TheInternetGnome (talk) 08:19, 30 January 2022 (UTC)
- Support ability to strip EXIF data from files, but not to rewrite. JPxG (talk) 00:55, 31 January 2022 (UTC)
- Support Per Pelagic's #3 Lrkrol (talk) 14:48, 31 January 2022 (UTC)
- Support -- Ahecht (TALK
PAGE) 18:34, 31 January 2022 (UTC) - Support for some fields JAn Dudík (talk) 21:11, 31 January 2022 (UTC)
- Support but is restricted to the uploader and admins to prevent vandalism. Thingofme (talk) 10:04, 1 February 2022 (UTC)
- Support Szymonel (talk) 13:47, 1 February 2022 (UTC)
- Support Ɱ (talk) 03:28, 3 February 2022 (UTC)
- Support restricted to the uploader and admins Giacomo Alessandroni let's talk! 14:45, 3 February 2022 (UTC)
- Support - Darwin Ahoy! 13:56, 5 February 2022 (UTC)
- Support Like JAn Dudík --Packa (talk) 23:20, 5 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:41, 6 February 2022 (UTC)
- Support DALIBRI (talk) 09:12, 6 February 2022 (UTC)
- Support —— Eric Liu(Talk) 09:35, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 17:15, 6 February 2022 (UTC)
- Support Toadspike (talk) 01:27, 7 February 2022 (UTC)
- Support Nave do Conhecimento (talk) 12:07, 7 February 2022 (UTC)
- Support ~Cybularny Speak? 21:17, 7 February 2022 (UTC)
- Oppose Not always files are googleable or discoverable by TinEye and then EXIF v. often is the only place where copyvio proofs are visible (especially if there is an original and real copyright holder provided). Masur (talk) 22:17, 8 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.
- More comments: Please and thank you.
- 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. ~~~~
User:1234qwer1234qwer4 (talk) 18:56, 11 February 2022 (UTC)
Voting
- Support JopkeB (talk) 06:31, 29 January 2022 (UTC)
- Support Thingofme (talk) 10:05, 1 February 2022 (UTC)
- Support Pi.1415926535 (talk) 21:57, 4 February 2022 (UTC)
- Support Gaurav (talk) 07:16, 11 February 2022 (UTC)
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)
Discussion
- @Pigsonthewing: 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)
- @Pigsonthewing: 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 (talk • contribs) 17:41, 7 February 2022 (UTC)
- @Pigsonthewing: 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
- [[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)
- 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)
- 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)
Voting
- Support JPxG (talk) 00:54, 31 January 2022 (UTC)
- Support but we have to improve the Wikidata page-number, same to my comments. Thingofme (talk) 09:52, 1 February 2022 (UTC)
- Support - Darwin Ahoy! 00:58, 5 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:43, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:55, 6 February 2022 (UTC)
- Support Marcok (talk) 08:05, 10 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.
- More comments:
- 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)
Voting
- Support Thingofme (talk) 10:07, 1 February 2022 (UTC)
- Support Daniel Case (talk) 23:16, 1 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 08:06, 6 February 2022 (UTC)
- Support --Ciao • Bestoernesto • ✉ 16:57, 6 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 (talk • contribs) 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)
Voting
- Support Need one similar to that of Archive.org. Vis M (talk) 20:52, 28 January 2022 (UTC)
- Support Lion-hearted85 (talk) 22:50, 28 January 2022 (UTC)
- Support Agree with @Vis M:: it should be inspirated by Internet Archive viewer. — ElioPrrl (talk) 11:20, 29 January 2022 (UTC)
- Support There are still serious bugs when uploading PDF and DjVu on Commons. --Yann (talk) 13:15, 29 January 2022 (UTC)
- Support Hemantha (talk) 15:31, 29 January 2022 (UTC)
- Support Cantons-de-l'Est (talk) 11:48, 30 January 2022 (UTC)
- Support JPxG (talk) 00:53, 31 January 2022 (UTC)
- Support the wub "?!" 14:31, 31 January 2022 (UTC)
- Support Sadads (talk) 16:02, 31 January 2022 (UTC)
- Support A possibility for scrolling the full pdf ou djvu should be fine. Havang(nl) (talk) 16:32, 31 January 2022 (UTC)
- Support --Alexmar983 (talk) 21:06, 31 January 2022 (UTC)
- Support JAn Dudík (talk) 21:08, 31 January 2022 (UTC)
- Support Yes, we mean we can read as pdf in google or edge, or some kind of file that says "Read whole file" Thingofme (talk) 09:57, 1 February 2022 (UTC)
- Support Daniel Case (talk) 23:24, 1 February 2022 (UTC)
- Support M0tty (talk) 09:54, 2 February 2022 (UTC)
- Oppose Major browsers (at least on desktop) already have PDF display capabilities. This seems to be asking for a duplication of that functionality which would be a waste of effort. Silver hr (talk) 18:01, 2 February 2022 (UTC)
- Support Yeeno (talk) 20:24, 4 February 2022 (UTC)
- Support — Bilorv (talk) 20:28, 4 February 2022 (UTC)
- Support Pi.1415926535 (talk) 21:57, 4 February 2022 (UTC)
- Support - Darwin Ahoy! 01:58, 5 February 2022 (UTC)
- Support HHill (talk) 14:19, 5 February 2022 (UTC)
- Support Peter Alberti (talk) 19:53, 5 February 2022 (UTC)
- Support DALIBRI (talk) 09:10, 6 February 2022 (UTC)
- Support Ayumu Ozaki (talk) 09:56, 6 February 2022 (UTC)
- Support 4nn1l2 (talk) 15:49, 6 February 2022 (UTC)
- Support —TheDJ (talk • contribs) 17:42, 7 February 2022 (UTC)
- Support BugWarp (talk) 00:08, 9 February 2022 (UTC)
- Support Ecritures (talk) 22:49, 9 February 2022 (UTC)
- Support Marcok (talk) 07:49, 10 February 2022 (UTC)
- Support Xavier Dengra (MESSAGES) 09:36, 10 February 2022 (UTC)
- Support Gaurav (talk) 07:12, 11 February 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.
- 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)
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 recommend further reading at
- c:User:JoKalliauer/SVG_test_suites, a current Bechmark for SVG-Renderer
- de:Wikipedia_Diskussion:Umfragen/Technische_Wünsche_2022_Themenschwerpunkte#Medieneinbindung_in_Artikeln_verbessern, the current Whislist for the German Wikipedia (don't forget to vote also there)
- mw:User:JoKalliauer/phab/wikimedia-svg-rendering#table, The table of all current SVG-Problems on phab:
- c:Librsvg_bugs, for the most prominent bugs
- A correction to the original proposal: Wikimedia servers are running librsvg 2.40.21 (not 2.40.2) which was released in 2020, but the entire 2.40.x branch was deprecated in 2017. -- Ahecht (TALK
PAGE) 18:26, 31 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)
- As disscussed in phab:T283083 and based on SVG_test_suites and phabricator-tasks I recommend to switch to resvg
- @Snævar and Ahecht: I would add:
- phab:T283083 (Hackaton-Session about re-evaluating SVG-rendering), phab:T11420 (textPath), phab:T35245 (list of x-coordinates), phab:T20463 (pattern), phab:T154237 ("lang=zh-hant"), phab:T280718(keep fontlist updated), phab:T180923(fallback-fonts), phab:T261192 (systemLanguage won't work with rust-librsvg>=2.44, so don't(!) update librsvg)
- phab:T36947=phab:T205776=phab:T142908 needs rust-librsvg2.50.6 which is newer than the librsvg-version of bullseye (newest stable debian-version).
- maybe also client-side-rendering: phab:T208578, phab:T134408, phab:T134455, phab:T134407, phab:T134482
- maybe we should inform the subscribers on phab of the most relevant/generall bugs of this whishlist, that they can add a comment?
- — Johannes Kalliauer - Talk | Contributions 14:43, 8 February 2022 (UTC)
- @Snævar and Ahecht: I would add:
- Would have supported if I knew voting ended at 18 UTC. ~~~~
User:1234qwer1234qwer4 (talk) 18:43, 11 February 2022 (UTC)
Voting
- Support * Pppery * it has begun 18:47, 28 January 2022 (UTC)
- Support --Arnd (talk) 19:55, 28 January 2022 (UTC)
- Support USI2020 (talk) 20:36, 28 January 2022 (UTC)
- Support --YodinT 21:13, 28 January 2022 (UTC)
- Support Femke (talk) 21:29, 28 January 2022 (UTC)
- Support — Draceane talkcontrib. 21:52, 28 January 2022 (UTC)
- Support. Preferably, viewing SVG files as native SVG would be a beta feature that would be off by default, and would eventually be turned on for everyone. Tol (talk | contribs) @ 22:24, 28 January 2022 (UTC)
- Support Lion-hearted85 (talk) 22:42, 28 January 2022 (UTC)
- Support -- Guerillero Parlez Moi 23:29, 28 January 2022 (UTC)
- Support Izno (talk) 23:41, 28 January 2022 (UTC)
- Support DonBarredora (talk) 00:48, 29 January 2022 (UTC)
- Support Certes (talk) 01:28, 29 January 2022 (UTC)
- Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:58, 29 January 2022 (UTC)
- Support Betseg (talk) 02:19, 29 January 2022 (UTC)
- Support