Last modified: 2013-06-25 23:45:16 UTC
When browsing a category containing images, only the first 20 characters of the image name are shown. However the end of the image name is particularly useful as it containes 1) the file type (png, svg, jpg, etc.), and 2) any extension like "-fr.svg" for diagrams in French or a number for a sequence of images. Therefore it would be useful to show the end of the image as well as the beginning. Maybe the image name could be shown on two lines instead of one, or maybe the last 6-7 characters could always be shown, with "..." in between, if the filename is too long to fit? Thanks.
I'm not sure we're going to see this happen since there is a wish to remove the file extension altogether -- see bug 4421. As for the language information, it wouldn't be necessary if bug 16052 - Support for multilingual SVGs was resolved. That said, if the fix for this bug is easy, we could do that as a workaround in the meantime.
This bug should certainly not wait for bug 4421, which is controversial and may well never happen, and in any case is not going to happen any time soon. There is a Javascript fix for this issue, but it's unsatisfactory because it means waiting for an entire category's image thumbnails to load before the Javascript kicks in. This should not be a particularly difficult or consequential bug to tackle; and in the usual way, it should create a new global MediaWiki option to turn on the new behaviour, and a per-user preference to turn it off.
Sorry, I should have specified: I think the "new behaviour" should be displaying the entire filename, except perhaps in cases of extreme length (over 2 or even 3 lines?), where it should be File:Beginning of name ...[bits left out]...end of name.extension.
There is more discussion here: *http://commons.wikimedia.org/wiki/Commons:Village_pump#Need_to_be_able_to_read_more_of_the_filename_of_images_in_categories It will eventually be archived here: *http://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2011/11 I think there should be a separate Bugzilla thread for how much of the filename should be shown in image categories on the Commons. There may be a very simple solution. Currently, 22 characters and spaces are being shown for filenames on the Commons. I would think that it would be a relatively simple thing to make that number an adjustable feature of the Mediawiki software. In the meantime it is probably simple to increase that number on the Commons.
A gadget fix has been implemented on the Commons. Maybe the JS for it can be adapted to fix this problem at a deeper level, in the Mediawiki software itself. See: *http://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-gadgets *http://commons.wikimedia.org/wiki/MediaWiki:Gadget-Long-Image-Names-in-Categories.js *http://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-Long-Image-Names-in-Categories.js
You have to set $wgGalleryOptions['captionLength'] to a higher value. Default is 25. INVALID for MediaWiki, maybe move the bug to Wikimedia/SiteRequest and add shell keyword.
(In reply to comment #6) > You have to set $wgGalleryOptions['captionLength'] to a higher value. Default > is 25. Will it be user-customizable then? I guess no. → MediaWiki bug. Not all users may like ultra long file names. A simple textbox in the userprefs containing the number of chars to be shown at max would be good.
No, it is not user-customizable, only for the whole wiki. It is a option, to make it user-customizable, but setting it on all wmf wikis looks easy.
(In reply to comment #8) > No, it is not user-customizable, only for the whole wiki. It is a option, to > make it user-customizable, but setting it on all wmf wikis looks easy. Yes, sure it would be easy - but it is not really an option to make it. A lot people will not like it, I guess.
Given that commons has js enabled by default to change this behaviour, how many people would really object to increasing the default for all of commons? Personally I don't like the idea of this being a per-user pref. Allowing prefs to super fine tune the interface to such an extent is bad for long term maintainability imo.
