Commons:Village pump/Proposals/Archive/2015/09

Template for huge SVG files

I've created a template for huge SVG files (>10 MB), because the MediaWiki software is unable to render thumbnails for these files. This is intended specially for complex SVG like maps.

• Could be this template useful, to be placed in the main Template: namespace?
• Are these huge SVG (like this file) be ussable, if them can be replaced with hight-resolution raster version with lower filesize?

--Amitie 10g (talk) 22:41, 7 September 2015 (UTC)

I like your new template and I do think that it should be moved to Template namespace. These huge SVG are not unusable, just unusable by our current software. They should be scaled down and reuploded under new name, but the full version should be kept as the source. --Jarekt (talk) 13:26, 8 September 2015 (UTC)

OK, your opinion should be enough. I'll move the template. --Amitie 10g (talk) 16:19, 8 September 2015 (UTC)

btw, I expect the limit is 10 decimal MB, which is closer to 9.5 normal MB (or MiB if you prefer). Bawolff (talk) 09:39, 12 September 2015 (UTC)

Removing lightbox previews in UploadWizard

Tracked in Phabricator
Task T112907

Hi, all!

As part of the changes we've been making to UploadWizard, we're updating the style of the dialogs used to display errors, display license previews, and so on. One dialog we're updating is the lightbox preview dialog, which you can summon by clicking on any of the small thumbnails in the deed or describe steps in the wizard.

My question to you is: Should we bother? Having a slightly bigger thumbnail of the image seems like a waste of time and code, and if we can axe this particular code path, it will simplify our lives in a few different ways. If nobody seems to actually use the lightbox, then we can safely delete it. If a few people do, then maybe we can learn about why and how, and possibly make the feature better.

Please let me know what you think here, or on IRC, or via e-mail if you prefer. Thanks! --MarkTraceur (talk) 18:40, 16 September 2015 (UTC)

I’d say you should not bother: Whoever is uploading anything is expected to have other ways to visualize the image(s), one Alt+Tab or Ctrl+Tab away. -- Tuválkin ✉ ✇ 00:06, 17 September 2015 (UTC)

I agree. I am using the upload wizard quite extensively (often uploading batches over 50 photos), and I have never needed a bigger preview. --Sebari (talk) 00:21, 17 September 2015 (UTC)

In fact I never even noticed its existence. :) Well, or maybe I noticed it few years ago and then stopped noticing. --Nemo 06:33, 18 September 2015 (UTC)

Me neither, but then again I rarely use the Wizard at all. If removing a bit of non-essential functionality makes it easier to get the UploadWizard work more reliably, then I'd say: Just axe it and don't look back. --El Grafo (talk) 13:19, 18 September 2015 (UTC)

User:Rillke/bigChunkedUpload.js is the only tool I use nowadays. Yesterday I'm a bit confused as the upload links are moved from "tools" menu to "edit source" as a drop-down menu. Jee 14:29, 18 September 2015 (UTC)

Available Download Resolutions

Hi, I'd like to discuss the different resolutions that are available to download on file pages. Currently, these seem to be the sizes where the long edge of the file is scaled to pixel counts of:

• 320
• 640
• 800
• 1024
• 1280

As far as I can tell, this system was introduced around September 2011. In my eyes, there is a number of arguments for adding higher resolution options here, if the servers can handle them:

1. The number of great files that we have that are larger than can reasonably be displayed in a browser for many people has grown significantly since then. If the browser refuses to display the full size, the next best option is the next smaller size that is offered - and that's 1280 pixels - not a size for enjoying any photo.
2. We ask for the highest resolution photo that a photographer is willing to offer. The argument is that you can always scale down but not scale up. That's a weak argument if the user can only view a 1280 pixel thumbnail of an image or the full resolution version that often does not look very good if viewed with a 1:1 screen pixel ratio. Generally, I feel like the largest option should be an option that is actually useful for most situations. In a recent discussion about FP standards, there seemed to be a consensus that most files should be judged at around 6 megapixels, which is somewhere between QHD and UHD. For someone viewing an image on a full screen monitor, that allows for a bit of zoom to see some more detail. It is also roughly what you get in terms of actual sharpness with decent photography gear and technique, in most situations, even if your sensor gives you a much larger file. As a result, at this size and with some sharpening, most files look good or very good at 100%.
3. Screens with resolutions of 1920 pixels or more had a less than 9% of total usage share in September 2011 according to statcounter.com data. This number has grown to over 17% globally (approximate numbers, I hope I didn't mess up the sums). So if people just want a wallpaper or a file that fills their screen for normal viewing, more of them are only left with downloading the full (sometimes huge) file nowadays. You can get a (good) 4k monitor for under $400 right now, so these are becoming common right now.
4. Many users need to download vector graphics as pixel graphics because the software they use (MS Word is one example) can't deal with svg files. That's sad, but it's a reality that we have to deal with. Currently, there are additional (mostly overlapping) download resolutions for svg files, most notably adding a 2000 pixel option. Even though that's much better than 1280 pixels, it's still not enough to see a lot of detail in many files. Small countries on a world map are hard to find, just to give one example. It's also not ideal that a separate tool is necessary for that.
5. Anyone can change to pixel size in the image retrieval url to a larger size. The server is happily serving me images at 8K and beyond. All that's missing are a few links for people who don't know that changing the resolution in the url is possible. If people don't need or use these, they don't put any load on the servers. If they do use them, I feel like that load is worth investing.

So to me, it feels like we should add a few more resolutions. The following ones seem reasonable to me:

• 1366 (#1 worldwide)
• 1440 (~#5 worldwide)
• 1600 (~#6 worldwide)
• 1920 (#2 worldwide)
• 2560
• 3840 or 4096

I would welcome a few opinions and thoughts on this, including good reasons why this would be a bad idea. Thanks, — Julian H.^✈ 11:06, 20 September 2015 (UTC)

•  Support With high-resolution "Full Frame" cameras becoming increasingly common, I would very much welcome having a preview image that actually fills my screen without having to open the full resolution file. --El Grafo (talk) 09:53, 21 September 2015 (UTC)
•  Support I have thought about this for some time. Thanks for taking the time to bring this up. Yann (talk) 09:55, 21 September 2015 (UTC)
•  Support, and glad that in the nominator’s planet 400 USD is petty change. -- Tuválkin ✉ ✇ 17:59, 22 September 2015 (UTC)
  • Didn't say that, but it used to be ten times that. A good monitor has never somthing that you can buy with petty cash. — Julian H.^✈ 05:59, 23 September 2015 (UTC)

Request for input regarding video proposal

Dear Wikimedia colleagues:

I am developing a proposal for a video series that's designed to introduce Wikimedia to new contributors (particularly in GLAM and education programs), and to motivate them to participate in the community in a constructive way. I would appreciate your input. The video is intended for translation into multiple languages; there are already volunteers for Spanish, German and Greek translation.

The proposal's main draft page is here.

The proposal talk page is here; it includes a draft outline of specific subjects that the video may cover.

Please note that the scope and budget of the project are still under consideration. At this point it would be especially helpful to have input on the subjects that the video should cover, and how best to cover them. This information will help as the project scope and budget are refined.

Please add your questions and comments to the talk page.

If you would like to support the project with your endorsement, please do so here

If you would like to volunteer to translate the video, please email me or comment on the talk page.

Thanks and regards, --Pine^✉ 23:35, 24 September 2015 (UTC)

Categories "looking more required" in UploadWizard

No-categories confirmation dialog

We have a patch (239418) for UploadWizard which will change how the category field works. If you don't enter a category, we pop-up a dialog (see picture) asking if you're sure you want to upload a file with no categories, and explains that categories are an important part of the Commons ecosystem. You can still upload files despite this warning, but it will make sure that users understand they should put categories on the file. I'm hoping to hear from people whether this is a worthwhile change, or if we should take it out. Thanks! --MarkTraceur (talk) 18:27, 23 September 2015 (UTC)

This was originally requested and developed two years ago (see phab:T51710), but it's always been broken and seemingly no one noticed. We're just restoring and refreshing the feature, assuming it is still wanted. Matma Rex (talk) 14:37, 24 September 2015 (UTC)

Yes, please do that! I'd also change the message to say something like "some categories" as the current wording (kind of) implies that one category would be the default. Maybe even include another link to Commons:Categories right there in the message (opening in a new browser tab)? --El Grafo (talk) 15:01, 24 September 2015 (UTC)

Thanks, I updated the wording in the proposed patch. A link to Commons:Categories is already present in the tooltip on the '?' icon next to the input field, I think that's enough.

Given that no one seems to mind it here, I think we'll go ahead with the change. Matma Rex (talk) 12:13, 28 September 2015 (UTC)

Retire Commons:Upload Wizard feedback and replace it with "How to file a bug report" page

This has been proposed by Jdforrester at phab:T112666 (and modified by AKlapper and Steinsplitter). Nemo bis objected because it wasn't discussed here first. So let's do this now … --El Grafo (talk) 10:15, 25 September 2015 (UTC)

As someone who goes through the entire feedback page backlog every now and then, I think the proposal is very harmful, because most people don't know how to login in Phabricator and forcing them to use it will effectively hide any problems in UploadWizard rather than help us fix them. Moreover, Phabricator cannot be used for two current legitimate uses of the page, namely

• writing in your own language,
• writing other comments not related to UploadWizard specifically (which can easily be moved elsewhere by someone who knows they aren't).

Finally, if you are really interested in helping improve UploadWizard, you should focus on getting the user-agent, which is the one missing piece which would be high impact and very easy: phabricator:T43291. --Nemo 06:31, 2 October 2015 (UTC)