On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke gwicke@wikimedia.org wrote:
Another option is to make this a property of the image rather than it's use site. That should cover the typical icon well, and with minimal editor effort.
Most images are hosted on Commons, so that would mean the Commons community would configure how images are used on other wikis. I am not sure if that is a good or bad thing. It would certainly mean less work for editors, and the work would be done by those who know the most about images. On the other hand different wikis have different conventions, and tend to take affront if conventions from other wikis are forced on them.
just reading through and one issue that stands out with (e.g.: [[file:foo.png|thumb|no-viewer|…]]). format is that many of the small image files are embedded within infoboxes, templates and tables would it be more efficient to restrict media viewer to only images that use the syntax [[File:foo.jpg|thumb|....]] within an article body ignoring images embedded with in {{.....}} and encourage editors to shift flags, small icons, maps etc into templates.
Alternatively just use the [[file:Foo.jpg|*thumb* |....]] as the key for media viewer to display otherwise it just ignores the file
On 13 May 2014 06:35, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, May 12, 2014 at 3:23 PM, Gabriel Wicke gwicke@wikimedia.orgwrote:
Another option is to make this a property of the image rather than it's use site. That should cover the typical icon well, and with minimal editor effort.
Most images are hosted on Commons, so that would mean the Commons community would configure how images are used on other wikis. I am not sure if that is a good or bad thing. It would certainly mean less work for editors, and the work would be done by those who know the most about images. On the other hand different wikis have different conventions, and tend to take affront if conventions from other wikis are forced on them.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On Mon, May 12, 2014 at 4:22 PM, Gnangarra gnangarra@gmail.com wrote:
just reading through and one issue that stands out with (e.g.: [[file:foo.png|thumb|no-viewer|…]]). format is that many of the small image files are embedded within infoboxes, templates and tables would it be more efficient to restrict media viewer to only images that use the syntax [[File:foo.jpg|thumb|....]] within an article body ignoring images embedded with in {{.....}} and encourage editors to shift flags, small icons, maps etc into templates.
MediaViewer uses the HTML code of the page to make decisions. Using the wikitext directly would create way more problems than it would solve.
Alternatively just use the [[file:Foo.jpg|*thumb* |....]] as the key for media viewer to display otherwise it just ignores the file
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...
On May 13, 2014 6:32 AM, "Gergo Tisza" gtisza@wikimedia.org wrote:
On Mon, May 12, 2014 at 4:22 PM, Gnangarra gnangarra@gmail.com wrote:
just reading through and one issue that stands out with (e.g.:
[[file:foo.png|thumb|no-viewer|…]]). format is that many of the small image files are embedded within infoboxes, templates and tables would it be more efficient to restrict media viewer to only images that use the syntax [[File:foo.jpg|thumb|....]] within an article body ignoring images embedded with in {{.....}} and encourage editors to shift flags, small icons, maps etc into templates.
Gnangarra's suggestion seems very sensible. Rather than mediaviewer launching trying to include everything, and being 'wrong' many times, causing community discontent and lots of 'emergency' editing, ... only enable it for a very large subset which will have very low negatives, and then have a productive discussion with the community about rolling the feature out on more images. Fine tuning.
MediaViewer uses the HTML code of the page to make decisions. Using the
wikitext directly would create way more problems than it would solve.
'thumb' already adds a css class to the HTML that you can use.
Alternatively just use the [[file:Foo.jpg|thumb |....]] as the key for
media viewer to display otherwise it just ignores the file
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...?
Maybe infobox templates could add the 'thumb' class in the right part of the html to trigger the correct viewer effect?
<gallery> also uses the 'thumb' class.
Does the mediaviewer register a pageview on the image page when the viewer is opened? If not, images on the mainpage may not be good candidates for mediaviewer, as that is one desired outcome of being on the front page.
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.
-- John
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. 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.
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...
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.
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...
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_sto...
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#mediavi...
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
Hoi, As I am heavily including images into Wikidata, I KNOW from first hand experience that the problem of images not being moved to Commons is a HUGE problem also there are many, many images in many projects that are just not in Common for many reasons.
What I find highly annoying is that this problem is belittled and called "a community problem" and "serves them right for not being free".
When we build tools they should accommodate all our environments and not only en.wp. Thanks, GerardM
On 26 May 2014 23:34, Federico Leva (Nemo) nemowiki@gmail.com wrote:
John Mark Vandenberg, 20/05/2014 02:45:
But many infoboxes have logos and low res nonfree content in the infobox.
Not so much outside en.wiki.
Nemo
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l