On May 20, 2014 2:46 AM, "Andrew Gray" <andrew.gray(a)dunelm.org.uk> wrote:
On 19 May 2014 14:50, John Mark Vandenberg <jayvdb(a)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_wildlif…
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_st…
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#mediav…
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
