On Fri, Jul 11, 2014 at 4:21 AM, John Mark Vandenberg <jay...@gmail.com> wrote:
> https://en.wikipedia.org/wiki/Indonesian_presidential_election,_2014
> http://stats.grok.se/en/latest/Indonesian_presidential_election,_2014
>
> The photo of Prabowo in MV has a caption of 'Prabowo wapres'
This happens to be the file's name, which is also the first thing
users see when they visit the File: page. Media Viewer uses filenames
for the titles because there is no consistently short
description/label available. It's been suggested to potentially move
the caption (when available, which it often won't be, or not in the
correct language) below the image instead, but this would lead to a
more inconsistent experience and would require making the font size
significantly smaller. In any case, it's something we can continue to
discuss. Fabrice's preference is to wait for the implementation of
structured data support for file description pages, and to then use a
multilingual "title" field (similar to the label for Wikidata items).
> instead of 'Prabowo Subianto' which is (now) the caption and alt text on the
> enwiki article, and the the Jokowi photo in MV has a caption of
> 'Gubernur DKI Jokowi' despite having an {{information}} block on
> Commons with an English & Indonesian descriptions, albeit without
> perfect syntax, but that is par for the course and MV design needs to
> cater for this type of scenario.
In this case it's doing the right thing -- pulling the only
description that has a language tag set. Pulling the surrounding text
as the default would likely be worse in far more situations. Media
Viewer respects the ?uselang= parameter and will show the description
in the desired language if available.
> Scrolling down on the Prabowo image in MV shows '== Licensing: ==' ..
> whoops wasnt wikitext supposed to be hidden?
You mean like it is here?
https://en.wikipedia.org/wiki/File:Prabowo_wapres.jpeg
> This is another syntax
> problem with the wikitext, but our goal should be to show broken
> wikitext to as many eyes as possible so that one person takes the
> initiative to try to fix it.
The Wikimedia Foundation mission statement is not "to show broken
wikitext to as many eyes as possible". Wikitext is a tool - and
ultimately this file metadata should be managed using a more
appropriate tool.
> The licensing shows 'CC-BY-SA 3.0', but
> the image is 'correctly' tagged as CC & GFDL.
Whether or not Media Viewer should show _all_ licenses or just
highlight the most usable one is a reasonable discussion to have.
Right now, it attempts to do the latter. IMO it should probably
recommend a default license above the fold, and show all others below
the fold.
GFDL is a license that requires re-users to include a full printed
copy of the text of the license with an image. It's nice that we're
offering it for some images in addition to CC-licenses, but except for
some very obscure cases, it seems unlikely that any user would
actually ever _need_ it. So offering this information in a less
prominent fashion seems appropriate.
> Scrolling down on the Jokowi image in MV shows Indonesian text instead
> of English text, it isnt identified as Indonesian language despite
> very good syntax in the wikitext
Media Viewer will pick the most suitable available tagged language and
render it. It might be useful to identify a non-English language as
such to guide viewers -- I'll file an enhancement request for that. As
noted previously, because Indonesian is the only language that was
tagged, it will pick that one. I've edited the file description to tag
English:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg#mediaviewer/File:Gubernur_DKI_Jokowi.jpg
And here it is in Indonesian:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg?uselang=id#mediaviewer/File:Gubernur_DKI_Jokowi.jpg
> and the 'License details' block on
> my screen shows the first two lines of the licensing template, and the
> top third of the third line of text which makes it unreadable, and a
> 'View more' sort-of-button which appears at the bottom right also
> overlapping with the second line of license text, obscuring that also.
> I can expand the box to show the rest of the license details, but ..
The fade-out indicates that the text is abbreviated and can be expanded.
> From an ideology perspective, these image pages have many issues which
> needed to be edited, and the MV doesnt promote editing. It shows
> dubious, incorrect, or syntactically invalid metadata as if it is
> un-editable, instead of suggesting that the metadata needs editing.
Yes - we definitely want to offer editing functionality in the viewer
down the road. This is directly tied to the work on structured data.
When fields like titles are stored as structured metadata, we can
potentially make them editable with a simple click action -- even
translatable! However, it would be unwise to build such functionality
now on top of wikitext. (We should determine whether we really want to
expose editing functionality to all readers in the viewer; as we've
seen with image annotation on Commons, we'll likely get a lot of
nonsense. But we can make that decision when we get there.)
> The slidebar has a sequence which repeats the images: Probowo ->
> Jokowi -> Prabowo -> Jokowi -> Prabowo -> Jowoki and then whooping
> huge Indonesia flag colors.
It's very unusual to have photographic images repeated in articles in
this fashion. MV should probably collapse the sequence, but that's a
minor and rare case. The flag only shows up because the template
doesn't use the "metadata" or "noviewer" class that exist for the
purposes of excluding images from the article sequence. Like other
examples, this is a case where clear machine-readable information can
only be added incrementally, but when it does get added, it helps us
for other purposes as well (e.g. any other process which extracts a
sequence of representative images from an article).
See:
https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer#How_can_I_disable_Media_Viewer_for_unrelated_images.3F
> And, there are also sorts of quite important parts of the licensing
> process which are ignored by MV.
> e.g. a image which is OTRS pending, now doesnt include a big scary
> warning one click away.
> https://en.wikipedia.org/wiki/Nick_Driver#mediaviewer/File:Nick_Driver_in_2013.png
Media Viewer is not the File: page, intentionally so. It provides a
summary view, not all information. We can discuss the inclusion
boundaries, but that will always be an ongoing process.
>>> sometimes you get resolutions which are silly (especially
>>> svgs at launch, but also slideshows on a file page include a very
>>> large license logo)
>>
>> Can you give a specific, current example?
>
> See above for the 'flag' example,
See above -- images can be excluded from the MV sequence by tagging
them with the "noviewer" or "metadata" CSS class as appropriate.
> but go to commons, click random
> file, open in MV, and scroll though all
I still don't understand the issue you're describing.
> You mean to say that after the launch, and after much anguish of the
> community telling the WMF that the extra click was a major pain point,
> this button was added.
There was always a method to obtain a full resolution copy, it just
took two clicks instead of one. The main concern was that the full
resolution original file may be in a format the browser doesn't know
how to render (correctly), or may be extremely large, so the team
wanted to avoid selling that as a "zoom" feature. So they ultimately
went with "View original file" which is intentionally a bit technical.
Long term we'd like to implement a proper zoomviewer-like zoom feature
in MV.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
