Jump to content

Commons:Village pump/Proposals/Archive/2021/01

From Wikimedia Commons, the free media repository

UploadWizard

Latest comment: 5 years ago2 comments2 people in discussion

The upload wizard works fine but if you need to add any copyright templates after, then it's kinda annoying to edit again. It's still okay but the upload wizard should have a section where you can add one those templates like {{PD-US}}. --Red-back spider (talk) 06:13, 26 January 2021 (UTC)

@Red-back spider: If you go under "not my own work", there's an option "Another reason not mentioned above" that lets you enter a custom copyright template. Is that what you're looking for, or are you talking about something else? Vahurzpu (talk) 18:30, 27 January 2021 (UTC)
@Vahurzpu: Oh, I never noticed that. Thanks!
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --Red-back spider (talk) 19:32, 28 January 2021 (UTC)

Include FastCCI to default settings

Latest comment: 5 years ago1 comment1 person in discussion

I recently discovered the tool FastCCI and I find it very helpful. I think it's especially helpful for those, who want to use good pictures in cats and sub-cats without navigating through deep category-trees. For people mainly writing WP-articles I would estimate, that they don't know the tool so well. So I would propose to set this tool to default activated.--Tesla - 💬 11:10, 23 January 2021 (UTC)

Basic upload form

Latest comment: 5 years ago14 comments8 people in discussion

The basic upload form input box is only 11 lines high. I use this a lot as I have prepared information templates ready to use. However, these are typically 15-20 lines high (depending on the number of categories to add), which means I have to resize the box with every upload, which is somewhat tedious. Can the Basic upload form input box be increased to 20 lines high, please? - MPF (talk) 18:33, 16 January 2021 (UTC)

 Support, makes sense.   — Jeff G. ツ please ping or talk to me 23:57, 16 January 2021 (UTC)
 Support yes, please, that's been bothering me as well on occasion. --El Grafo (talk) 06:21, 22 January 2021 (UTC)
 Comment - thanks @Jeff G. and El Grafo: for the support! What is the next step in the process? Do I just wait for it to be done (in roughly how long?), or is there some other action needed? - MPF (talk) 21:53, 22 January 2021 (UTC)
@MPF: One of your colleagues should judge the consensus, and then someone can start a phabricator task for it.   — Jeff G. ツ please ping or talk to me 21:59, 22 January 2021 (UTC)

England by county

Latest comment: 5 years ago10 comments3 people in discussion

I think we should revise the England by county (for example, Category:2010 in England by county) so they are no longer locked into twelve monthly categories for CatScan and allow us to include the actual counties into them. As you can see Category:2010 in England now has 72 subcategories but many dozens are the actual counties. It seems both complicated and confusing to have categories for counties (and to include the same counties there on a monthly basis) but not the county there for the year. -- Ricky81682 (talk) 06:20, 7 January 2021 (UTC)

Also note that a number of cities (Leeds, for example) are in both England and the county subcategory at the same time rather than the city subcategory (Category:History of England by city) so it gets confusing very quickly. In contrast, the US categories are organized by state and city separately. -- Ricky81682 (talk) 06:49, 8 January 2021 (UTC)
  • Alright, I've done it myself. Does anyone think it makes more sense to incorporate Wales (principal areas now, districts pre-1996) and Scotland's council areas into a whole subdivisions of the UK group as it's a mess across the nation over time? -- Ricky81682 (talk) 06:28, 3 February 2021 (UTC)
I notice this with countries all the time, for example departments in France Vs. cities in France. Municipalities in the Netherlands Vs. cities in the Netherlands. I personally prefer to use "cities" exclusively as they rarely change borders as much, meanwhile counties can be reformed by political decisions. The problem is that counties are an abstract country subdivision in which their geography is determined by culture, history, and whatever the central government of the United Kingdom wants, cities are cities. While cities merge from time to time, counties reform all the time. I think that "Places in England by location" should have counties and cities and then each county can have all the cities (note that "city" here means any human settlement regardless of size) within them. Note that "Leeds" refers to the city but the "City of Leeds" actual describes a more abstract subdivision. --Donald Trung ă€ŽćŸ”ćœ‹ć–źă€ (No Fake News 💬) (WikiProject Numismatics 💮) (Articles 📚) 18:10, 5 February 2021 (UTC)
  • @Donald Trung: By location becomes more complicated as you have civil parishes and villages which some counties have trees for (but not a full history tree). To be 'complete' (that will never happen), you sort of end up with a 2020 in England by location followed by England by village/by civil parish/by city/by county with the county at least being a sensible container category. I only got involved because city is only international consistent subdivision. And yes, Category:Canterbury versus Category:City of Canterbury is what it is. In the end, it's all about trying to create a "useful" organization, not a perfect one. -- Ricky81682 (talk) 18:45, 5 February 2021 (UTC)
  • It works well enough as it is. Counties in England do not vary much- that last major reorganisation/renaming was in 1974. Cities are within counties. No need to change anything. Just consider them as separate, parallel but side-ways linked trees. Please leave well alone. Rodhullandemu (talk) 18:28, 5 February 2021 (UTC)
  • @Rodhullandemu: They are separate parallel trees at least within England. I built them all that way for the most part. The question was for Northern Ireland, Scotland and Wales which have cities and sort of organization by the other subdivision. -- Ricky81682 (talk) 18:45, 5 February 2021 (UTC)
  • I spent years working on Scottish Council Areas, the current major subdivisions. Ceremonial counties are historic and have only two minor purposes today. Pretty much the same in Wales except they are Principal Areas, some being called county boroughs. But in both, cities are within the next level up division, except possibly Swansea and Cardiff, which are cities, counties and principal areas all at the same time. I don't know about NI, but again, the distinction should be obvious. Rodhullandemu (talk) 19:10, 5 February 2021 (UTC)

Add Instant Save button

Latest comment: 5 years ago5 comments5 people in discussion

@Gryllida: If your computer or your browser crashes in the middle of your hard editing work, it'll be very frustrating that you'll have to do it ALL over again. Or, if you want to take a break from editing, you'll need a save button so your work is saved but not published. Gryllida (not me) created this code which adds a "Instant save" button to the editing page if you have the code. If somebody would add this to everybody or make it a setting you could choose it would be awesome. --Red-back spider (talk) 03:25, 24 January 2021 (UTC)

Note: untested with edit conflicts. Gryllida (talk) 03:26, 24 January 2021 (UTC)

Keeping PDF and DjVu duplicates

Latest comment: 5 years ago33 comments15 people in discussion

This proposal is to establish the community consensus that when PDF and DjVu copies of documents exist on Commons, both should be kept. This would exclude corrupted files, and allow for upgrading file quality, such as recompiling the document with better scan images or embedded OCR text.

Background

In the last four months, the COM:IA books project has released over a million documents on Commons, mostly public domain books, and this has highlighted the need to establish this rule as many are available in both formats. If this is established then we can proceed with cross-linking versions, and consider the conditions for a project that might mass upload DjVu versions of specific documents or types of document that are of interest to sister projects.

In the non-Wikimedia world, PDF for documents is the de facto standard for documents that can be read by our reusers and stored across all platforms, browsers and mobile apps. The Internet Archive abandoned the DjVu format in 2016 due to unreliability, though they are still available for a significant proportion of the collection of several million documents. We also recognize that DjVu is considered a more convenient format for supporting our editors on WikiSource, and for this reason some notable documents uploaded in PDF by default, would benefit from having the DjVu format also being made available.

There is a precedent for defaulting to keeping multiple formats of the same file, because it is a norm to keep alternate formats of jpeg and potentially superior SVG versions created from them, or TIFF and jpeg formats created from those which are far more compact and have more accurate thumbnail rendering. Commons' project scope was adapted back in 2008 to address PDF and DjVu formats, and since then there never has been a consensus to prefer one format over the other.

Related

Thanks --FĂŠ (talk) 20:23, 20 January 2021 (UTC)

Vote on keeping both PDF and DjVu duplicates

  • I have questions. IAUpload will re-ocr texts but not when the pdf exists here and uses the IA template. So, that is a big problem for "co-existance" arguments. Also, is popularity really a thing? How is that measured? Use, maybe? Which filetype is used more? I really have no problem keeping both formats, but IAUpload being disabled due to shared templates is a problem that should be handled before any voting proceeds.--RaboKarbakian (talk) 22:05, 20 January 2021 (UTC)
  •  Support same with all duplicates in different formats. Better linking of these files could be done by structured data in the future. --GPSLeo (talk) 22:19, 20 January 2021 (UTC)
  •  Support Retaining duplicates of PDF and Djvu , but Issues with IA upload 'blocking' upload of the sister format need to be resolved. The other concern is that in some cases the PDF quality is lower than the DJVU, with no automatable metric for determining where this from in scan quality on conversion has occured. Ideally for some works, doing the PDF/DJVU generation on a WMF server directly from the JP2 or TIFF scans, to ensure the highest quality possible would be the way of gettingrealyl high quality. However, this has a disadvantage of large file sizes. A possible third solution is for ProofreadPage and the Commons media viewer/thumbnailer to be extended so it can retrieve JPEG/JP2/TIFF page scans directly from a ZIP file, and treat the entire ZIP file the way it would a multi-page documents. IA seems to do soemthing like this for showing indvidual scanned pages in it's web based viewer. ShakespeareFan00 (talk) 11:46, 21 January 2021 (UTC)
  •  Support I'm concerned about replacement; when I build a DJVU file, I often remove duplicate pages, which means it's not a drop-in replacement for Wikisource. Going forward, I'd love to say we should be using only PDF, but compare the pages at s:Index:Weird_Tales_Volume_3_Number_1_(1923-12).pdf to the PDF at File:Weird Tales Volume 3 Number 1 (1923-12).pdf in your webbrowser. The second is perfectly readable, but the first is unusable.--Prosfilaes (talk) 00:45, 22 January 2021 (UTC)
  •  Support per FĂŠ.   — Jeff G. ツ please ping or talk to me 01:39, 22 January 2021 (UTC)
  •  Support makes sense to me. --El Grafo (talk) 06:20, 22 January 2021 (UTC)
  •  Neutral I do not really have an preference. There is an vocal majority on en.wikisource on DjVuÂŽs side and I copy that sometimes. Mainly wikisource users need to have the option to upload an improved version (as OCR is stored in the file itself), but I do not think the file extension is a big deal. It is also a fact that DjVu will die out eventually, as PDF is much more prominent and the number of DjVu programs in active development are dwindling.--Snaevar (talk) 01:26, 23 January 2021 (UTC)
  •  Support, as different file types make them different files, even if the content is identical, it is important that both are usable. --Donald Trung ă€ŽćŸ”ćœ‹ć–źă€ (No Fake News 💬) (WikiProject Numismatics 💮) (Articles 📚) 17:56, 5 February 2021 (UTC)
  •  Support, per GPSLeo reasoning.--Vulphere 04:17, 6 February 2021 (UTC)
  •  Support--Tesla - 💬 08:32, 6 February 2021 (UTC)
  •  Support When they're based on the same scan, I do wish we had a way of linking them together beyond just adding a link, but that's a whole other deal. I don't see a downside, based on current practice, to keeping both at this time. — Rhododendrites talk |  15:45, 13 February 2021 (UTC)
  •  Oppose In the end, I feel that this is a temporary solution for a much bigger issue. The real solution would be import the jp2 files and either support them natively or convert them to png offline. Then, we can use a bot to replace all the images on wikisource with the original images available at various resolutions per the usual wiki practice. DJVU and PDF are both significantly inferior to original images. I also agree that we should automatically redo the OCR. Tesseract has improved and using full quality images will probably generate better results. I know that this is a larger project, but it’s crucial for supporting wikisource. Allowing for duplicates will just create a bigger mess to clean in the future. Languageseeker (talk) 19:27, 6 March 2021 (UTC)
  •  Support DjVu and PDF have significant differences and different use cases. Also, a plea: whenever making decisions like these regarding PDF and DjVu (or other "book"-adjacent stuff), please notify the Wikisourcen that it's happening. Wikisource has unique needs that are not immediately apparent if you think of PDF/DjVu as just weird image formats. @Languageseeker: In what way would the current proposal hinder the theoretical future one you're outlining? Why would you oppose a solution to a real problem affecting people now in favour of a pie-in-the-sky alternative that, at best, would be a long-term, goal? --Xover (talk) 22:57, 6 March 2021 (UTC)
    • @Xover: I thought about this carefully and the history of technology is littered with the messes made by competing technologies: vhs vs. betamax; high-8 vs. vhc-c; D-VHS v. HD-DVD v. blu-ray. Each one of them led to a significant amount of wasted time. Here are some of the specific things that I'm worried about on Wikisource.
    1. The inadvertent creation of duplicate index pages and transcription projects. If we are to allow DVJU and PDF versions of the same file, then we would need to create a system for checking to make sure that an index page with the same IA identifier does not exist. This would require coding which would pull resources from more important long-term projects. Or, administrators would have to delete Index pages that some user worked on risking their alienation.
    2. Neither PDF nor DJVU contain the full quality of the original images. Therefore, at some point, we would need to switch to the full images anyway. Until we do so, here are some immediate downsides
      1. Users have a difficult time proofreading texts and can become discouraged.
      2. Substandard OCR makes it difficult to proofreading, driving away volunteers and wasting time on unnecessary corrections.
      3. Image crops may be based on substandard images that will need to be redone. This can be extremely disheartening to volunteers who have spent significant time making good images from an inferior copy, see [[File:Gentlemen Prefer Blondes (1925) p. 21.png]].
      4. Moving from PDF or DJVU to the original images can cause page images to shift. The longer we wait the more page numbers and text shifts we will have to do.
    3. DJVU is an obsolete format. It will only become harder to support it in the future.
    4. In the end, I think that we need to push Wikimedia to allocate funding for Wikisource so that we can get a decent interface. Adding a hack to fix a bigger problem just leads to more headache. Languageseeker (talk) 02:05, 7 March 2021 (UTC)

Discussion on PDF and DjVu duplicates

Briefly picking up on some of the points raised in votes so far:

  1. Wikisource:DjVu vs. PDF states as a matter of known fact that PDFs are more widely known and supported than DjVu files. Many users can find it easier to create and edit PDFs for this reason and PDFs may be easier to acquire than DjVu files. I don't have a survey or similar to assess this, perhaps someone can find an expert reliable source or article that is more recent than the IA blog post of 5 years ago?
  2. References to blocking and coexistence issues, I think are in relation to the exists-normalized error which the MediaWiki software returns when an upload attempt is for a file with the same filename apart from file extension type (this is actually a misnomer, potentially an undesirable bug, ref mw:Extension:UploadWizard/Error behavior, as the error trap has been extended beyond the "normalization" of file mimes but is triggered on any extention, i.e. ".jpeg" is treated as equal to ".JPG" but also ".jpeg" trips this error when ".tiff" exists). In my own batch upload projects this has been necessary for mass uploading jpegs when the TIFF exists. This can be ignored by an upload bot, and I don't know if the upload wizard has a trick to ignore it, but there is really no "security" issue in having this as an option when the error is encountered, so in my view it should be allowed more easily for experienced contributors.
  3. I would not use structured data to hold information about duplicates, keep in mind that these currently invisible fields are not possible to handle using the API, while if the information is in the image page text (as it is for literally millions of files in GLAM collections with embedded galleries, crops and cross-links) then these can be instantly found and mass corrected using either special API based scripts or existing well understood tools like VFC.

The comments about shared templates I don't understand, that's not an error condition as far as I'm aware.

The comment about re-OCR text I don't understand, unless this is about WikiSource parsing, which is outside the intent of this proposal. All PDFs from the Internet Archive have been OCR'd and this text is available inside the file metadata and can be queried using the Commons API without having to locally download the whole PDF, which is important considering the PDFs may be hundreds of megabytes while the text for the same file is often a fraction of a meg. As a tangent, let's jointly recognize that document display on Commons is TERRIBLE, and there should be a more urgent WMF development project to make it at least as nice as the Internet Archive has made available, for free, for years. --FĂŠ (talk) 11:30, 21 January 2021 (UTC)

FĂŠ {{Internet Archive link}}. https://ia-upload.toolforge.org Pick a favorite or random pdf from your uploads, and put the "assession" number into it. Adjust the form to request djvu. You will see that the "machine" there will check and deny. Release the pdf from the template and try again. That brings you to the next set of options. Adjust those form elements to new ocr from jp2 origs. 2021 tessaract is soooo much better than 2005 or 2009 versions. The sourcerers had many problems to solve and did. On a personal note, my combined edit count (previous user accts) for here is great -- yet, there was so much the sourcerers had to teach me. Dismissive attitudes should be to Flickr experts and the like. The 'pedia experts are here and commons serves them.--RaboKarbakian (talk) 12:45, 21 January 2021 (UTC)
Dismissive attitudes, that's not the intent here. We are discussing a factual guideline that can work for Commons and WikiSource users, and that Commons tools can be aligned with.
Remaking the OCR would be worth doing, no contest, but that's an upgrade project we can discuss for any format, not just PDF. Similarly Shakespeare's point about fully remaking documents from scratch using the JP2 which we cannot currently host on Commons, but could potentially host in a different way as an archive backup on WMF servers.
It would be neat if we could host a "document" in multiple formats using one object (folder) on Commons, including the OCR text as an accessible raw text file that itself could be refreshed with better recognition when available. Fundamentally the MediaWiki software already handles "documents" as a package of images, so potentially that can be a much more useful design principle. But these are scenarios for significant improvement projects that this proposal does not encompass.
With regard to the IA-upload tool, I have never used it. I understand there are basic problems with it, and if it does not allow a DjVu or a PDF when the other format exists on Commons, that's a bug in my book and it happens to be one that I know can be fixed. On a practical note the number of uploads by IA-upload run at at least two magnitudes less than the IA books project is running at, so in terms of volunteer time, the prioritization remains on IA books. --FĂŠ (talk) 13:45, 21 January 2021 (UTC)
IAUpload uses the template I linked to. If a bot could change your uploads to just use the url as sourcd, all would be well. Its a pity you didn't try it and then "create" an index file at source. The <pages /> magic there is impressive.--RaboKarbakian (talk) 15:37, 21 January 2021 (UTC)
Ref User_talk:FĂŠ/IA books#Metadata, the suggested template is used. --FĂŠ (talk) 18:34, 21 January 2021 (UTC)
  • [moving to discussion section to avoid too much noise in the votes]
    @Languageseeker: This is a vote to establish the community precedent ("policy" if you will) that Commons can continue to host both PDF and DjVu versions of the same scan. It requires no software changes or other effort beyond this discussion, and it essentially just formalises the status quo. In fact, in this vote, "oppose" is the vote that triggers resource expenditure in amending policies and practices to the change, and establishing processes to account for it. As a practical matter it would probably also force Wikisource to start hosting a larger number of files locally instead of on Commons.
    Since a large chunk of IA's scans have already been bulk uploaded, not allowing both versions would mean we were stuck with an often inferior (both image quality and OCR) version where the PDF is of poor quality (which it often is). I routinely upload a DjVu version of a particular scan to replace a PDF, where I have used minimal compression settings, full image resolution, generated new OCR, and removed Google Books ad pages, or fixed page order or other issues. Not allowing both would mean I would be unable to do that, or at the very least would mean I would have to have a community discussion (essentially a deletion discussion) to establish my version as the superior one that should be kept.
    Keeping both, however, costs us nothing. The user confusion you adduce is trivial. There is so much confusion around different editions of works and different scans of the same edition, that the extremely few cases where having both file formats even shows up on the radar is entirely insignificant and is easily offset by the flexibility it provides. If by some miracle we eventually manage to shake loose the resources from the WMF (good luck) to support .jp2/JPEG2000 directly, having PDF and DjVu versions of the scans here already would be no obstacle to bulk uploading those individual scan images. If by some further miracle we manage to get support for creating an index based on a category of images (or whatever) in Proofread Page (and some as-yet-not-defined mechanism to handle the OCR, which image file formats do not support, unlike PDF and DjVu), any existing index referring to a PDF or DjVu could simply be moved over and automatically gain the better images.
    Having just one format would also artificially force us to choose different stakeholders to prioritize. For Wikisource, currently, DjVu is by far the better format and having only PDFs would be painful. But for the rest of the world, and those wishing to use the scans directly, rather than our wiki versions of them, PDF will be the preferred format by far. Why would we artificially force a choice between these when we can trivially (by merely deciding to do so) support both? --Xover (talk) 09:27, 7 March 2021 (UTC)
"The real solution would be import the jp2 files", no this is a fantasy solution. This has been discussed several times and requested, but it's never going to happen and the WMF are not investing in it. It's nowhere even being near the Agile watermargin for development. --FĂŠ (talk) 11:16, 7 March 2021 (UTC)
I think that WMF is reluctant to natively supporting JPG200 because it's a niche format. Here is the process that I propose that mostly happens offline
  1. For a given Internet_Archive_ID (IA_ID) download the following: IA_ID_bhlmets.xml IA_ID_dc.xml IA_ID_marc.xml IA_ID_meta.xml IA_ID_orig_jp2.tar IA_ID_scandata.xml IA_ID_toc.xml
  2. Offline, extract IA_ID_orig_jp2.tar to a folder. Add in the other files. Zip and upload to Commons for storage. Do not delete the unzipped files.
  3. Offline, use ffmpeg to convert the individuals images to png and delete the JPG2000 files.
  4. Offline, Use the information in IA_ID_scandata.xml to automatically crop the images.
  5. Offline, perform a tesseract OCR on the pngs and generate separate files for each image. Place the tesseract hOCR or ALTO files into the same folder.
  6. Offline, zip up the files into IA_ID_png.zip
  7. Upload, IA_ID_png.zip to commons
  8. Here is the major change to Wikisource: We will need to be able to load images and the text from the zip file instead of PDF or DJVU. Perhaps, add a source image section to the Index template. German wikisource does something similar already.
This shouldn't be too much programming as much of this would take place offline in a batch file.@Xover: @FĂŠ: , I would value your input on the feasibility of this proposal. Languageseeker (talk) 17:23, 7 March 2021 (UTC)
This would be exceptionally pointless. The JP2000 files are at IA. They will not be hosted at Commons. There is no reason to transcode many terabytes of JP2000 files to huge PNG files when they are sitting ready to use in JP2 on any project by anyone by reading from IA on demand.
A logical proposal would be integration with IA for documents in the Wikimedia universe, the WMF partnering with IA to ensure both organizations are backed up by the "endowment" fund and if better tesseract OCR work is needed, that the new readings update the txt files at IA before playing around with them at our (literally) second order projects which are not consistent mirrors of the archive. A realistic first step would be for WMF dev to inherit some of the document reading and searching capabilities from IA; in the process, the WMF could even offer to be a partner on some of their bugs and improvements. --FĂŠ (talk) 20:34, 7 March 2021 (UTC)
Genuinely confused, are we suggesting that we merge with IA or that our projects pull directly from IA instead of Commons? Languageseeker (talk) 21:22, 7 March 2021 (UTC)
@FĂŠ: Let me respond to you in greater detail. I propose mirroring the files from the IA because it's uncertain how long the IA will last. They have engaged in some practices that has exposed them to lawsuits and they still have lots of content that potentially infringes copyright. Storing the original scans is cheaper that having to rescan the books in the future. Tying WMF to IA can potentially embroil us in their legal troubles such as the Open Library lawsuit.
You also seem against the creation of high quality pngs. This entire debate exists because Wikisource needs higher quality images. Without them, we cannot proofread some texts and can only create substandard quality crops with the crop tools. At present, if we want to add an illustration, we need to go the IA, download the JP2 archive, extract it, find the correct files, crop it, convert the image to PNG, and then upload it to Commons. That takes so much time. If we had high quality pngs, then any user could use the crop tool to add images in seconds. Yes, we will create larger pngs, but we need them. Languageseeker (talk) 01:58, 8 March 2021 (UTC)
The IA has a 100 year plan, the WMF doesn't even have a 5 year plan.
If the IA goes down, its content is already elsewhere, but the WMF could easily make a commitment to keep a mirror of PD content. As for better integration, that could be as simple as better automatic linking to IA JP2 for pages within a book identified for transcription, or providing PNGs on-demand without necessarily needing to publish as files on Commons. There's lots of ways to prepare this vegan friendly Jambalaya, there's no need to publish a recipe before suggesting it for lunch next month. In the meantime, consider supporting this proposal, there's nothing here that contradicts your concerns for better solutions, but this proposal helps both projects in the meantime. --FĂŠ (talk) 12:13, 8 March 2021 (UTC)
If we can grab files from the IA on demand, they why even have DJVU or PDF files on common? The same logic applies. I think that it's a big ask to request that IA transforms all the JPG files into PNG files. Perhaps, they have the original TIFF somewhere, but that seems even more pie-in-the-sky.
Linking to the JP2 files would require WMF to commit to writing a JPEG2000 decoder into the wiki software, which you state it has refused to do so.
Wikisource does not need high-quality images on occasion, but on a regular basis. That's why we need to have a easy access to high quality png that we can easily manipulate.
I'm against the proposal because it will create millions of duplicate files of inferior quality. I'm not just thinking about the vegan friendly Jambalaya for lunch next month, but for the next century. Temporary solutions have a nasty habit of becoming permanent. Languageseeker (talk) 01:55, 9 March 2021 (UTC)
@Languageseeker and FĂŠ: Is the reluctance to support JP2 files immediately due to technical or licensing reasons, or both?   — Jeff G. ツ please ping or talk to me 03:19, 9 March 2021 (UTC)
@Jeff G.: From what I can tell the proposal was made in 2017 and stalled in 2018.
Tracked in Phabricator
Task T161934
Languageseeker (talk) 03:32, 9 March 2021 (UTC)
@Languageseeker and FĂŠ: Thanks, that task had slipped my mind. Please see my new proposal #Commons should support JP2 file format, below.   — Jeff G. ツ please ping or talk to me 04:26, 9 March 2021 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2021/01&oldid=1103117031"