Extension talk:Media Viewer/About

How can I have data on all the languages of comment
Some pictures are commented in various languages. For example. I can not see the comments in all languages with the new visioner. So I might add a comment in a language that already exists.

How can we solve that problem?

--Lucyin (talk) 11:14, 16 May 2014 (UTC)

Why the captions are omitted?
Well, I'll try to be constructive this time. I don't understand why the cutlines/captions are omitted. I mean, without them, the most of the images from an encyclopedia are meaningless, since they are used for improve the explications and not just for decoration. Besides, many of them are diagrams or pictures with numbered parts like this that must have a caption. ¿Why not to include them? Thanks. Albertojuanse (talk) 00:26, 26 April 2014 (UTC)
 * +1. I noticed the same big problem. Most of all a serious lack into comparative galleries. --Salix (talk) 16:30, 27 April 2014 (UTC)
 * They are only omitted on galleries (that bug has been fixed, but the fix has not been rolled out yet). If you do not see the caption for any image that is not inside a gallery, could you provide a link? --Tgr (WMF) (talk) 06:59, 28 April 2014 (UTC)

No, I mean, this is not a bug report, Tgr. What I mean is that I tried the "beta" on esWiki and, when I clicked on an image, there was not the caption of the picture, the explanation of it. Of course, there was the file description and copyright mark, etc; but no the explication which is under the image in the "normal" MediaWiki view.

My point is that without these captions, the explanation of that image, this software is "useless" for a project like Wikipedia, in which the explanations/captations of the image are needed for understand it (maybe not for other proyects, of course, talking about Wikipedia). Thanks. Albertojuanse (talk) 15:20, 28 April 2014 (UTC)
 * Albertojuanse: I think Tgr point was that the no-caption in galleries was a bug which has been fixed since.
 * Unless you feel (like Salix) that the caption should be displayed without scrolling down to the hidden metadata panel, which is tracked on 64132. Does the bug report accurately describes what you are expecting? Jean-Fred (talk) 16:46, 28 April 2014 (UTC)
 * ¿Is it scrollable!!!!!? Then, sorry, Jean-Fred and Tgr, the captions are shown properly when you scroll it.
 * Then, you have to find a way for making people know that the page is scrollable!!! I have no even notice that, so I guess other people won't either. Thanks. Albertojuanse (talk) 11:32, 29 April 2014 (UTC)

Media Viewer problems
Hi! My experience with Media Viewer has so far been mostly negative. Here are some points:
 * It presents a cleaner interface, but at the same time it hides a lot of valuable information from view.
 * It seems to have a very different interface compared to the normal Commons experience, which may be confusing.
 * I've witnessed at least two instances, where another user could not escape out of Media Viewer in an easy and straightforward manner (no menus etc visible).
 * It seems Media Viewer has gone default on some Wikipedias – including plwp. My preferred browser (Mozilla Camino 2.1.2) doesn't seem to be compatible with Media Viewer, and I'm not proficient enough in Polish to be able to deactivate Media Viewer in my plwp account. This is not good.

If any or all of these things could be addressed, I'd might be more positive to its implementation. But as for now it's a big no-no for me.--Paracel63 (talk) 12:28, 26 April 2014 (UTC)


 * I now found the deactivation command info in the discussion above. Thanks for that.--Paracel63 (talk) 12:48, 26 April 2014 (UTC)


 * BTW, there doesn't seem to be a way of deactivating Media Viewer "in advance"? Next week, I still want to be able to reach Commons, with my preferred brower, through any of these Wikipedias "Dutch, French, Japanese and Spanish". Best of wishes. :-)--Paracel63 (talk) 12:56, 26 April 2014 (UTC)

"Normal Commons experience" is a bit of an oxymoron. Commons file description pages are disorientating jumbles of random information, looking at a cleaner interface after getting used to them might be a bit like taking off the reversing glasses in the perceptual adaptation experiments :-) Yes, change is always confusing, but there is no way to avoid that if we want to transition to a saner user interface.

I've witnessed at least two instances, where another user could not escape out of Media Viewer in an easy and straightforward manner (no menus etc visible) - do you mean that they could not figure out how to exit, or that the normal methods of exiting (X mark, Esc key) did not work? If the latter, can you reproduce that?

Do you have any specifics of how MediaViewer breaks on Camino? Do you get a javascript error, or does it work but look ugly?

--Tgr (WMF) (talk) 07:18, 28 April 2014 (UTC)


 * Hi! Thanks for getting back to me. Yes, Commons of today is a mixed experience, which clearly could need an overhaul, bringing the composition of the content a lot clearer (like an easily accessible standard attribution line for each license and a lot less bulky license presentation).


 * However, what I've seen of Media Viewer does not seem guided towards (active) users of Wikipedia but as a standalone image viewing environment. It's a media viewer per se, but getting important info out of view has its cons. The lack of visible navigation aids is not for me.
 * Those two instances of failed escaping out of lightroom were with the same user, who used MSIE (a later version) on Win7 (or Win8), itself a menu-less experience that is far from my idea of an easy-to-use computer working environment. The whole setup may have been unstable in at least one of the instances, where we resorted to having to restart the whole computer. In the other, earlier instance we were not prepared nor instructed of how to navigate in lightroom.
 * Yes, on Camino I get a JS error: "Error loading Media Viewer: Module oojs has failed dependencies".
 * Sorry if I'm misunderstanding some things with Media Viewer. As I spend my Wikipedia days 99.9 percent of the time through Camino, I may have missed some good points. Now looking at it through Firefox and plwp, I can appreciate the clean interface. But the cons are the same: lots of valuable info hidden out of view. As a contributor to Commons and Wikipedia this thing just isn't for me, and I'm wondering why the current Commons interface couldn't have found a – somewhat less radical – design change instead? MV looks too much like a gadget, and IMHO it should have stayed that way. The oft-repeated explanation around Media Viewer that "change is always confusing" is sounding like a political statement, so I'm not going to comment on this further. Best of wishes--Paracel63 (talk) 13:52, 28 April 2014 (UTC)

--Tgr (WMF) (talk) 18:45, 28 April 2014 (UTC)
 * Tracking the Camino issue as 64562.
 * If by "not guided towards active users" you mean it does not have editing features, it would be very hard to present an interface to change data with the way currently things are stored, in big blobs of wikitext; and it would be a waste of time, sine that is planned to change soon, at least for images hosted on Commons, with the introduction of Wikidata. After that happens, it is possible that MediaViewer will get some editing features.
 * That said, we did make some changes based on the needs of power users (the image page link in the bottom right corner that's accessible without scrolling, for example), so if you have more suggestions, please share them.
 * Commons file pages have just way too much information for their own good. We might be showing less then ideal for a power user (mostly because extracting them from the file page is a lot of effort), but any user-friendly redesign of how readers access file metadata has to start with hiding a lot of it.
 * There were several reasons why not to redesign the file page itself: it would break established workflows (if you don't like MediaViewer, you can just skip it and go to the file page; if the file page itself would be changed, you would be probably much more unhappy); it is a based on a wiki page so it has a lot of baggage from step 0; it is on a different wiki, and that presents a lot of usability problems (lack of cross-wiki preferences, notification, identities...); loading a new HTML page per image is a horribly ineffective way of navigating images.


 * Thanks for the explanation. As long as I can avoid Media Viewer and have a well known, editable workspace, that's enough for me. I notice at Bugzilla that the bug won't likely be followed up upon, as Camino is no longer being developed. If anyone can point me to a modern browser that has a 1+1-button (= easy one-hand access to all the standard editing/tab interfaces) access key standard on OS X, I'd be willing to pay quite a handsome sum of money. The very best of wishes.--Paracel63 (talk) 15:30, 10 May 2014 (UTC)

It takes my time, I hate it
New viewer may have some positive features for viewers, but I found it irritating. As editor I switch to Commons to use the file, edit page or find information on usage of my photo on other wiki. This new viewer is ugly, uploads slowly and needs another click to find what I am looking for. I want to disable it, but did not found how (it is a default feature on cz:wiki)--NoJin (talk) 10:11, 27 April 2014 (UTC)
 * + 1. Many files take more than 5 seconds to focus, and I have a very good fiber Internet connection ! --Salix (talk) 16:35, 27 April 2014 (UTC)

As a fellow editor, can I ask something ? Are both of you aware of shift/command/middle/right clicking an image to open in a new window ? For me clicking links like that is 2nd nature, but I know many users are not used to that. I have warned before about how many editors we have who might not be used to accessing images that way and predicted friction regarding this with the mediaviewer. I think that makes it a good case to give people an easier opt out (ask auto confirmed users on first click, and disable the feature with JS, if the user thinks it is undesirable). TheDJ (talk) 10:50, 28 April 2014 (UTC)
 * I hate it too, how can I turn it off? --Korvatunturi (talk) 09:11, 16 May 2014 (UTC)

Description is not very understandable
MediaWiki:Multimediaviewer-pref-desc currently says (my comments in brackets): "Improve your multimedia viewing experience with this new tool [So far, so good, but what does it do?]. It displays images in larger size on pages that have thumbnails [Hm, so it expands the thumbnails, making them a little larger?]. Images are shown in a nicer [nicer than?] fullscreen [full-window?] interface overlay, and can also be viewed in full-size [full-screen? full-size being 100 % (with scrollbars if necessary)]."

What about "Improve your multimedia viewing experience with this new tool. When thumbnails are clicked, a larger version will be shown in a nice-looking overlay, which can be expanded to full screen if desirable. Media on the same page can easily be navigated." ? Danmichaelo (talk) 09:54, 27 April 2014 (UTC)

Error loading MediaViewer: localStorage is null
When clicking on image, error "Error loading MediaViewer: localStorage is null" is displayed. --Ragimiri (talk) 13:46, 27 April 2014 (UTC)

Hi Ragimiri, what browser/OS are you using? Could you try adding  to the URL before opening MediaViewer, then opening the browser's error console (F12) and copying the error message here? --Tgr (WMF) (talk) 18:12, 27 April 2014 (UTC)

I am using Firefox 28 on Windows 7. I hope, this is it:

"Use of "mwCustomEditButtons" is deprecated. Use mw.toolbar instead." load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017 "Use of "addOnloadHook" is deprecated. Use jQuery instead." load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017 "User clicked on thumbnail to open lightbox." load.php:11931 "localStorage is null" load.php:10015 Výpis zásobníku z load.php, funkce mw</<.log</log.warn, řádek 10017. load.php:10017

--Ragimiri (talk) 18:24, 27 April 2014 (UTC)

Might be 64525 --Tgr (WMF) (talk) 07:35, 28 April 2014 (UTC)

Of course I have DOM storage disabled. But there is no reason to use DOM storage to viewing images on wiki. --Ragimiri (talk) 08:37, 28 April 2014 (UTC)

The reason is to avoid annoying users with the same notification endlessly. There is no reason a disabled localStorage should cause a JS error, of course - we are feature-detecting it the wrong way. --Tgr (WMF) (talk) 18:13, 28 April 2014 (UTC)

Superfluous
The Media Viewer is a superfluous, unnecessary and harmful tool, which makes work harder. Commons is not a gallery but tool for work. When we go to the commons, we don't want watch and delight pictures, but obtain information necessary for writing of articles. --Matrek (talk) 04:22, 28 April 2014 (UTC)
 * Media Viewer is meant to work differently on Commons than the other wikis since viewing file pages on Commons is part of the work flow and is much more important than the visual experience we are trying to provide. If you feel that there are ways that Media Viewer can be better integrated into Commons so that it does not interfere with workflow by all means toss out your ideas here. There is always room for improvement for integrating with Commons. Keegan (WMF) (talk) 21:47, 29 April 2014 (UTC)

How this off
I dont know, how it function off.--Toma646 (talk) 17:48, 28 April 2014 (UTC)
 * If Media Viewer is already enabled for all, like it is here, you can disable it in your appearance section of your preferences. If Media Viewer is not enabled for all and is still in Beta Features on your wiki, you can disable it in Beta Features. Keegan (WMF) (talk) 18:48, 29 April 2014 (UTC)

What about most users who do not have an account? how can they turn it off as most will want to?--Michel le tigre (talk) 20:55, 12 May 2014 (UTC)
 * Like any feature in Mediawiki that someone does not like, they can register an account and adjust their preference to suit their needs. Keegan (WMF) (talk) 18:26, 15 May 2014 (UTC)

Alternative
I've had this script enabled for some time now, and I feel like it's a much better alternative than Media Viewer. I'd much rather stay on the same page and just click again when I'm done with the picture, video, etc, rather than having to go to a new page then hitting the Back button and waiting for the page to load again. Supernerd11 (talk) 14:32, 2 May 2014 (UTC)

Useless and annoying
My first word would be "What the fuck ?" Before, when you would see an image at a 100% scale (typically maps in SVG format), it was simple : click on the image, you got on the file page, another click on the image and then you had it in your browser. And now ??? With this media viewer it's impossible to have the file at 100% in the window... The "full screen" button ? Totally useless. The "download" options ? Impossible to download the source SVG, PNG only is available ! But Firefox can display SVGs ! Worst evolution of Wikipedia EVER. I'm not english so excuse my syntax. Bob Dean 2014-05-02 21:29 UTC Edit : Okay, you could get the file on Wikimedia Commons two other clicks away... Still boring.


 * 100% agree. Most idiotisk plug-in. Wonder why people would put any efforts in a such a useless thing. Image should give clear and direct access to just two options: text information (caption, copyright, categories) and 100% and/or fullscreen view. If these options are obscured - it is just an annoying obstacle.78.73.55.57 18:39, 9 May 2014 (UTC)


 * PS will you instead do something usefull, e.g. this : Project:Requests, so I will appear myself? 78.73.55.57 18:44, 9 May 2014 (UTC)

From Tucvbif
From Russian Wikipedia: -Gryllida 15:18, 3 May 2014 (UTC)
 * 1) Incorrect translation, 'learn more at wikiemdia commons' as 'подробнее на скада', should be "подробнее на складе", other tense of the noun, I tried to find at translatewiki and there is the 'подробнее на $1' bit but not the 'склада';
 * 2) how to link to a mediaviewer preview from wikilink. PageName tries to find a heading, and fails.

--Tgr (WMF) (talk) 17:53, 3 May 2014 (UTC)
 * 1) You can translate here and here. Usually this sort of stuff is done with   (  or something like that - what options GRAMMAR has depends on the language, I don't know how it is used in Russian).
 * 2) The link format is  . You can use   in templates:   will result in [#mediaviewer/ link]. (We should probably put this in a FAQ somewhere.) Read this mail if you are interested in how this format came to be.

Multiple licenses
The Media Viewer has a confusing experience for multi-licensed images. For example, File:Populus angustifolia CO.jpg is multi-licensed under CC BY-SA 3.0 as well as the GFDL. When viewing this image in the Media Viewer, however, the image name is accompanied by a CC logo and the text "CC BY-SA 3.0". However, this text is linked to the GFDL:



This image is tagged with, which takes multiple licenses. In this case, the page has the CC BY-SA 3.0 metadata followed by the GFDL metadata. It would be much less confusing if the viewer would consistently pick a license when more than one is found, and ideally it would show all of them.

– Minh Nguyễn (talk, contribs) 21:38, 3 May 2014 (UTC)


 * Hello Minh Nguyễn: Thanks for bringing up this issue, which is now high on our priority list. Here is our development ticket for handling multiple licenses. We are working with our designer Pau Giner to come up with a simple solution to let users know there is more than one license without cluttering up the user interface: for example, we might show an ‘other license’ link next to the first license label, linking to the License Details where that second license would be shown in full. We're open to other approaches, as long as they are easy to develop and can displayed in a compact way to users. Thanks for taking the time to report this issue. :) Fabrice Florin (WMF) (talk) 17:55, 13 May 2014 (UTC)

Please roll it back
It's not pleasing nor useful, in my opinion. I liked it just the way it was before. Changing things just for the sake of 'advancement' is entering the road to oblivion. I'm sure there are other useful inventions that could be implemented. Put resources on that. Please. --OSeveno (talk) 22:10, 3 May 2014 (UTC)

A supprimer d'urgence
C'est nul, c'est moche, ça ne sert à rien, un retour en arrière sur l'ancienne fonctionnalité serait une décision intelligente.Piso17 (talk) 11:23, 5 May 2014 (UTC)

Sorry, most maps become illegible
The new Media viewer is a big setback for maps on Wikipedia. The reason: there's no "zoom to 100%" feature in the new media viewer. As most maps are contributed on high resolution, the maps become illegible. In fact, I get messages from users asking if I have changed my maps. No, I haven't; a poor viewer has been installed and here's how you turn it off: go to your preferences, select the tab "appearance" and disable "Media viewer" under the "files" section. Wikipedia team: please turn this viewer off by default, or add a zoom feature in the new viewer. 82.157.194.130 16:46, 5 May 2014 (UTC)
 * This is planned in a future release (can't tell which, the URL does not load for me, which I hope is just a problem with my connection). Gryllida 10:30, 6 May 2014 (UTC)
 * Thanks for bringing up this issue, which many of pointed out to us as well (a zoom feature is by far the most frequent request in our surveys). To address this problem, we are now working on this simple link solution (#588)], which we hope to release in coming weeks. It would either link to the original image outside of the Media Viewer, or to the ZoomViewer gadget, developed by Dschwen. If we have more time later this year, we may be able to develop a built-in solution inside Media Viewer, such as this Basic Zoom feature (#504) -- or the more labor-intensive Full Zoom feature (#167) cited by Gryllida. Either way, we will provide a simple zoom capability shortly, as it is clearly needed (see Gerrit #132133). Thanks for your patience. Fabrice Florin (WMF) (talk) 17:18, 8 May 2014 (UTC)
 * to give an different example, also texts become illegible. to open the original file and use the browser or operating system image viewer to view the image it takes 5 clicks, instead of 2 before. --ThurnerRupert (talk) 13:12, 10 May 2014 (UTC)
 * You can click on the commons/site icon to go to the file page directly, so it is only +1 click. Also, you can use "Use this file" > "Download" > "preview" which is 3 clicks but probably actually faster than the old 2 click method because you don't need to wait for the file description page to load. --Tgr (WMF) (talk) 21:30, 16 May 2014 (UTC)

License link
In lightbox mode, a license is shown next to the file name, below the image. Unfortunately the license links to its English text, even though I am viewing on Russian Wikipedia, and I had set Russian interface language on both sites (Russian Wikipedia and Commons). Gryllida 10:12, 6 May 2014 (UTC)

We rely on license templates to get the links. If the template is localized, this might be a bug (depending on how it was localized - there are several methods and we don't support all of them), otherwise MediaViewer just does not have access to the right information. --Tgr (WMF) (talk) 15:49, 6 May 2014 (UTC)

Full-screen button
The documentation mentions a full-screen button (two arrows) at the right of an image, but I don't see such button in Media Viewer (not on Russian Wikipedia nor here). Gryllida 10:14, 6 May 2014 (UTC)
 * The button is not displayed if your browser does not support the Fullscreen API. If it does support it, and you think this is a bug, please add browser details. --Tgr (WMF) (talk) 15:52, 6 May 2014 (UTC)

When speaking of the «Use this file» tool, the documentation says «Also, please include all required credits and links to comply with those terms: these credits are included in the Download panel, where you can copy and paste them for your purposes.». However I do not see such information included in the Download panel (not here nor on Russian Wikipedia). Gryllida 10:27, 6 May 2014 (UTC)
 * That part has not been implemented due to lack of time. --Tgr (WMF) (talk) 15:52, 6 May 2014 (UTC)
 * Hi Gryllida, thanks for reporting this issue about the lack of attribution info in the Download panel. I have filed this ticket for it, so we don't lose track of this requirement: #598 Show attribution credits in download tool. Due to our limited bandwidth, we may not get to it right away; so for now, I recommend we change the FAQ to have folks look for that attribution info in the Embed panel, which I will do later today. Thanks again for bringing this up! All the best :) Fabrice Florin (WMF) (talk) 21:55, 14 May 2014 (UTC)

How to justify the text
I know this is not the place but if you can help me... I would like to set in my preferences the old feature "justify the text". How can I do it? --Circuit-fantasist (talk) 18:07, 8 May 2014 (UTC)

CC BY SA with GFDL link
For images like File:"After Franz Hals" by Lawrence Saint.jpg which are dual licensed, media viewer shows license as CC BY-SA 3.0 with a link to GFDL (CC BY-SA 3.0) while accessing from the Wikipedia article. J ee 16:32, 9 May 2014 (UTC)
 * Same issue as . --Tgr (WMF) (talk) 17:09, 13 May 2014 (UTC)

Link title to the source page in Commons
Why not link the title to the source page in Commons? It is the "best practice" to satisfy the attribution requirements as in the most prominent location. J ee 15:35, 14 May 2014 (UTC)
 * I think of the title of the file is similar to how you see File:FileName at the top of the page except now it's at the bottom, and there's a link to the Commons page. I'm fairly certain our layout satisfies the attribution requirement. Keegan (WMF) (talk) 20:50, 14 May 2014 (UTC)
 * It's OK, if you think so. I just pointed the CC recommendation as we already provided a link to the license just right of the title. CC recommends, "title" with a link to source + "license name/icon" with a link to the license deed/legal code. (You can see here how I implemented it in a very prominent location.) J ee 02:16, 15 May 2014 (UTC)

Did not understand it, turned it off - no exif information
I like to see exif information, I might not be a good photographer but I enjoyed seeing that information. I tried to see it using the new interface but couldnt. Therefore I created an account to be able of turning it off. I use Google Chrome but assume the functionalities of the feature is fully harmonized with that browser
 * You can disable Media Viewer by (while logged in) un-select your "Enable new media viewing experience" under Files. You have to do this for each wiki. After that you'll be taken to the file page directly. Hope that helps. Keegan (WMF) (talk) 07:24, 15 May 2014 (UTC)
 * It is not ready. Another VisualEditor type implementation. Titodutta (talk) 16:25, 16 May 2014 (UTC)

Disabled
I couldn't see or add categories in Commons, disabled it immediately as I do a lot of file organisation. HelenOnline (talk) 21:14, 15 May 2014 (UTC)
 * Thank you for letting us know how Media Viewer did not mesh with your workflow. I'll be sure to contact you should we enhance category support in the future. Keegan (WMF) (talk) 23:21, 15 May 2014 (UTC)
 * I have disabled too. Titodutta (talk) 16:23, 16 May 2014 (UTC)
 * Titodutta: I appreciate you letting us know. Was it for the same or similar reasons as HelenOnline, or another reason or two? Feedback for what didn't work for you would be great. Keegan (WMF) (talk) 23:24, 16 May 2014 (UTC)
 * Above I see you say that it is not ready. What needs improved? Keegan (WMF) (talk) 00:08, 17 May 2014 (UTC)

How to disable MediaViewer for some images




We’ve been discussing on the multimedia and commons mailing lists various ideas for disabling Media Viewer for some images that are confusing to users. For example:
 * metadata images (e.g. small icons, flags), which are not related to the page's topic;
 * other images that do not render well, making them unsuitable for Media Viewer (such as maps using weird CSS/JS tricks, or images which use a clipping template).

We initially discussed the idea of creating a special CSS class (e.g. class="noviewer") to mark these images and prevent them from showing up in Media Viewer, as proposed on [this ticket #511]. But after exploring this idea on the mailing lists for a while, we didn't hear a strong consensus, with a lot of diverging responses -- which may suggest that this original proposal to use a separate class may not be the best solution for addressing this issue. We're also getting increasingly concerned that using a separate class (e.g. ’noviewer’) that it could introduce more confusion for our users, due to inconsistent usage (with some editors disabling certain images in some places, but not in others).

So we would like to propose a simpler approach, which would be to use existing methods to disable Media Viewer for some images, such as adding a "metadata" class or a link parameter, as proposed in the FAQ draft below.

What do you guys think of that approach? Is there a more practical solution we haven't thought of? If this new proposal works for you, would you recommend any changes to the wording of the FAQ? Fabrice Florin (WMF) (talk) 17:58, 16 May 2014 (UTC)

PROPOSED FAQ (To be added to our 'Help FAQ Page' once we reach consensus.)

Sometimes, Media Viewer displays images that are confusing for our users. This includes metadata images (e.g. small icons, flags), which are not related to the page's topic; other images do not render well and are not suitable for Media Viewer (such as maps using weird CSS/JS tricks, or images which use a clipping template).
 * How can I disable Media Viewer for unrelated or unsuitable images?

We invite editors to prevent these images from appearing in Media Viewer, using one of these two methods: To enable users to access file information, consider adding a link in the file’s caption, so people can still access its file information page:
 * For metadata images, simply add this "metadata" class for unrelated images like icons or flags:
 * For images that are not metadata, but which don’t really render well in Media Viewer, consider using a 'link parameter' to disable them in Media Viewer:

Other methods may be available to exclude images in Media Viewer, but we encourage community editors to start marking metadata images right away, using the first method above, since that is work that should be taking place anyway.

(End of proposed FAQ)

________________________

Comments

 * I've read the mailing list discussion and I was surprised to see that nobody had mentioned link=|, so I'm glad that's covered above: as I understand, that disable mediaviewer, right? Is there any evidence that using link= is not enough to solve most problems? --Nemo 18:12, 16 May 2014 (UTC)
 * One problem with link=| is that it blocks the path to Commons, which is is how we often find the images. I do not think we want to block link to commons only to the Media Viewer. One of the issues with blocking the link to Commons is that many images are shared on CC licenses which require the user of the image to attribute the image creator. Right now that requirement is fulfilled by the link, but without link (or the attribution text on the page) those files become copyright violations.  --Jarekt (talk) 18:58, 16 May 2014 (UTC)
 * Thanks, Nemo and Jarekt. Nemo, I'm glad you think link=| might work for this purpose, but share Jarekt's concern about linking to the file page, so people can see attributions and license info. This is why I proposed adding that link in the caption, so people can still access that info. This could be done with a script like: . I realize that this is not the most elegant solution, but in rare cases where this is needed, it would do the trick. If that's not good enough, we could consider a new class like 'noviewer', but wanted to explore all currently available solutions before introducing more complexity. Fabrice Florin (WMF) (talk) 20:30, 16 May 2014 (UTC)
 * only works with thumbnail formats which do not have a visible caption, IIRC. For non-PD images it's possible to do horrible things like  but I would rather not go there. The main use case for this is tricky CSS-using templates, I think (position map, labeled map, clipped image etc) and it possible to add the link as a part of the template there. Usually much less disruptive than sending the user to the file page on any image click, too. --Tgr (WMF) (talk) 21:26, 16 May 2014 (UTC)

My use cases for Wikipedia and Commons
I generally like the concept of Media Viewer used on Wikipedia; however it makes little sense to me on Commons, where most of the time when we click on a file is because we want to see or edit its metadata or categories. None of those tasks can be done well with the viewer, which is not able to show data stored in more advanced infoboxes like c:template:Artwork (go to c:Category:Mona Lisa and click on one of the images), and which is not able too show/edit categories. I think it should be disabled by default on Commons. My main purpose of clicking on images on Wikipedia is to: Only first task is helped by the current version of Media Viewer, but I think it is more useful than current going to the wikipedia clone of the commons file page, which often does not handle commons templates well. So with or without Media Viewer, most of the time it takes me 2 clicks to get where I want to go to. However to be fair, I think it is perfect for average Wikipedia user who is not involved in the projects. --Jarekt (talk) 18:50, 16 May 2014 (UTC)
 * enlarge the photograph
 * see the metadata (see above),
 * ensure the image is properly categorized,
 * find matching category with other related images (Commons have interwiki links to Wikipeia, but Wikipedia does not have interwiki links to Commons :(some articles use en:template:Commonscat but it is hard to find on the large pages), or
 * check if image have annotations identifying people or objects.


 * Yes, I agree on Jarekt’s opnion: descriptions in are shown quite incorrectly.


 * And, yes, the Media Viewer is in whole useless for an editor. May be, it would be liked by non-editing readers. But... It seems to me, that the Media Viewer can transform the informative, encyclopedic Commons into one of numerous photo hostings, just into a storage of nice pictures... Dmitry Ivanov (talk) 19:54, 16 May 2014 (UTC)
 * Thanks for letting us know how Media Viewer fits (or doesn't, should I say) into your work on Commons. Currently the Viewer is designed and built to help you consume what you are seeing. I can see why it wouldn't be helpful to work on Commons because it's not for working, it's for viewing. Perhaps we can work in some editing functionality in the future, but that's not on the table at the moment. I hope that you do get the opportunity to use Media Viewer when you want to just look through images :) Keegan (WMF) (talk) 21:05, 16 May 2014 (UTC)