On May 20, 2014 2:46 AM, "Andrew Gray" <andrew.gray@dunelm.org.uk> wrote:
>
> On 19 May 2014 14:50, John Mark Vandenberg <jayvdb@gmail.com> wrote:
>
> >> There are images that do not use that syntax but we want to display them,
> >> for example infobox main images, gallery templates, images on the main
> >> page...
> >
> > But you could launch without the infobox images...?
>
> I think this would be pretty confusing - the infobox is the primary
> image for most articles (often the only one) and it would seem very
> strange to trigger it for other images but not this one.

But many infoboxes have logos and low res nonfree content in the infobox. If these are not going to be viewed in the new mediaviewer, the confusion you mention will already exist. Some UI design is needed so the reader knows whether clicking an image will launch the mediaviewer in-page or will load the media's file: page.

> That said, a
> filter of:
>
> * is in one of the following "content" templates [infobox and variants]; or
> * is called with |thumb|; or
> * is in <gallery>
>
> would seem to get most of the "content" images; the challenge would be
> building the template whitelist on a per-wiki basis.

... or use a list of wikidata Qids for templates.

> > Also the mediaviewer commons image parser doesnt work well for complex
> > pages, such as images typically seen on the frontpage of the projects.  The
> > mediaviewer for Sitta europaea wildlife 2 1.jpg (on en.wp mp right now) only
> > gives the filename - the description is missing.
>
> This is indeed a complex image - the description seems to be embedded
> in a hand-coded table.
>
> https://commons.wikimedia.org/w/index.php?title=File:Sitta_europaea_wildlife_2_1.jpg&action=edit

That was just an example. There are lots of html descriptions. Even more are plain text descriptions, and these show the description and then say ~ 'no description available'.

And even odder cases like local copies of Commons media.

https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Please_stop_this_project.21

> IME, this is relatively unusual for frontpage highlighted images -
> they have rich metadata, certainly, but it's usually in a standardised
> form that the mediaviewer should be able to interpret.

Agreed, and frontpage media can be updated to work with mediaviewer as part of the nom. process, if that doesnt requie degrading the metadata. (however pageviews is still an issue)

I could easily raise 100 bugs against this new feature if I had a few days free, many of which I would considered to be critical, but will infuriatingly be marked as an enhancement because it wasnt in the design doc that only exists in the brain of the product manager.

E.g. The infobox image here says nothing about licensing:

https://en.wikipedia.org/wiki/World_of_Warcraft

A bit of finger pinching on my phone sends the UI into meltdown.

Then there are the small things like circa causing a UI wording issue in English at least. https://en.wikipedia.org/wiki/St._John_the_Baptist_in_the_Wilderness#mediaviewer/File:StJohnWildernessBosch.jpg

Im sure many other people will be also raising similar quantities if bugs, resulting in lots of duplicate reports. Who is going to triage the large influx of bugs and how much manpower has been assigned to fix the bugs? Problems raised two weeks ago havent been fixed yet. This looks like it will be a VE-style deploy. :-(

Has the WMF come up with an estimate of the percentage of Commons image pages that the parser is 100% extracting the appropriate metadata.

--
John