On Fri, Jul 11, 2014 at 4:21 AM, John Mark Vandenberg jayvdb@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/...
And here it is in Indonesian:
https://commons.wikimedia.org/wiki/File:Gubernur_DKI_Jokowi.jpg?uselang=id#m...
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_disabl...
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_20...
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