Page MenuHomePhabricator

More prominent display of other format available for download in image description pages
Open, MediumPublicFeature

Description

Author: mcdevitd

Description:
See this mockup from Jean-Fred: https://commons.wikimedia.org/wiki/File:Mock-up_TIFF-JPEG_fullsize_-_Wikimedia_Commons.png

Where certain file formats (like TIFF, SVG, PNG, etc.) also offer full-resolution "previews" in a more user-friendly (and browser-friendly) format like JPG, we should be making this more obvious to the users who might want to download/view that instead of the original file. Right now, the prominent link is to "Original file". During a Commons Village Pump discussion Jean-Fred mocked up how we could make this option more visible to the users, with a "Full Resolution in JPEG" link of equivalent size and placement as the "Original file" link currently is.


Version: 1.23.0
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25148

Details

Reference
bz62305

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:03 AM
bzimport set Reference to bz62305.
bzimport added a subscriber: Unknown Object (MLST).

I am all new to Wikimedia development and am willing to be a contributor. I wish to work on this bug as my first fix.

See this mockup from Jean-Fred: https://commons.wikimedia.org/wiki/File:Mock-up_TIFF-JPEG_fullsize_-_Wikimedia_Commons.png

Seems like too much information (and space), we don't normally display file size, mime (etc.) of thumbnails.

How about these ones (for single and multiple formats respectively)?

file_format_links_mockup_1.png (791×1 px, 539 KB)

file_format_links_mockup_2.png (792×1 px, 539 KB)

As i have understood, according to the mockup that you have provided, I am first supposed to change the text under an image which said 'Orginal File' to 'Full Resolution:' and then provide a mean of downloading the original file in its original uploaded format as well as in JPEG format.
So I thought of taking a top down approach by first editing the text under the image and then implementing the download option. But i am having a difficult time in figuring out where the HTML code for the page showing the image lies. I was expecting a file somewhere that generates the HTML code needed for that page to display. I ran the project in debugging mode and looked line by line in execution as that page loaded but still could not find any where that had the words 'Size of this preview:' or 'Other resolutions:'. Can you please give me any clue on this?

IMHO the proposed mockups are not making clear what the original format (the one in which edits must be made) is.

I ran the project in debugging mode and looked line by line in execution as that page loaded but still could not find any where that had the words 'Size of this preview:' or 'Other resolutions:'. Can you please give me any clue on this?

Translatable strings are in the languages/i18n directory; you can find the internal message key there and grep for that.
The HTML is generated in ImagePage; we don't have anything nice like a separate template page, I'm afraid.

In T64305#956760, @Tgr wrote:

Translatable strings are in the languages/i18n directory; you can find the internal message key there and grep for that.
The HTML is generated in ImagePage; we don't have anything nice like a separate template page, I'm afraid.

Thank you for the help. I managed to add the download link to the bottom of the image just as you had shown in the mock up.

@Tgr

Seems like too much information (and space), we don't normally display file size, mime (etc.) of thumbnails.
How about these ones (for single and multiple formats respectively)?

I did not quite understand what you meant in that comment by "single and multiple formats". Were you telling something like if the original image itself is a jpeg just show the link to the original file there, otherwise show the link to the converted jpeg image as well as the original file there?

Another thing that I am in doubt is that as I understood the mapping files in languages/i18n directory is used to support multiple languages so that displaying the page in different languages can be done by simply changing the json file the page refers to. Yet the file formats like jpeg, tiff would still be the same in every language. So isn't making and including keys for all the possible file types I would be showing under the image in the en.json file unnecessary?
Or shall I just use them as strings in the ImagePage?

IMHO the proposed mockups are not making clear what the original format (the one in which edits must be made) is.

So maybe keep the original link where it is now and only put the alternative format to the rest of the links?

@Tgr
I did not quite understand what you meant in that comment by "single and multiple formats". Were you telling something like if the original image itself is a jpeg just show the link to the original file there, otherwise show the link to the converted jpeg image as well as the original file there?

Yes, for JPEG/PNG/GIF (probably a few others which I forget) there is no conversion so only the original needs to be linked, other formats are converted into something all browsers can display and that should be linked as well.

Another thing that I am in doubt is that as I understood the mapping files in languages/i18n directory is used to support multiple languages so that displaying the page in different languages can be done by simply changing the json file the page refers to. Yet the file formats like jpeg, tiff would still be the same in every language. So isn't making and including keys for all the possible file types I would be showing under the image in the en.json file unnecessary?

When something should not be translated (and you are right that file types should not) and you need to incorporate it into a larger message, you can use parameteres ("Original format: $1"). You can find the details of message handling here.

In T64305#968851, @Tgr wrote:

@Tgr
I did not quite understand what you meant in that comment by "single and multiple formats". Were you telling something like if the original image itself is a jpeg just show the link to the original file there, otherwise show the link to the converted jpeg image as well as the original file there?

Yes, for JPEG/PNG/GIF (probably a few others which I forget) there is no conversion so only the original needs to be linked, other formats are converted into something all browsers can display and that should be linked as well.

I'm sorry if i'm causing you trouble. I just want to make sure i understood correctly what you really meant. Please correct me if i'm wrong.
So for a JPEG image, right under the image something like only "Full resolution: JPEG" should be there?
and same goes for a PNG and GIF files as well(something like only "Full resolution: PNG" and only "Full resolution: GIF" respectively)

And for other formats (I think you must be referring to ones like SVG, TIFF am I right?) media wiki automatically converts them to something that all browsers can display.
I just checked for it here, it is a SVG file and it provides those other format links in PNG.
And here, it is a tiff file and clicking other resolutions would give a JPEG file even though it is not expilicitly and clearly mentioned.
So you are saying that only for formats like that, those PNG or JPEG links of the maximum possible image size also should be clearly provided right under the image in addition to the link to the original file?

If you look in the media handler class you will notice a mustRender method. That controls if the file is always converted or if the original can be used.

Some formats support multiple thumbnail types (specificly tiff which supports png and jpg). Thats hard to detect though. For now, Id reccomend just using the getThumbType method to figure out what formats the thumbnail is. (https://doc.wikimedia.org/mediawiki-core/master/php/html/classMediaHandler.html may be helpful to you).

Note on jpegs: if they have exif rotation then they are always converted.

There might be complications with this feature in that for large images we will probably oom if making a thumbnail the same size as the file

(Hopefully that helps. If i want on a cell phone or id write more vebosely)

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:23 PM