Last modified: 2014-10-06 08:23:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T73690, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 71690 - MMV: Viewer displays strange "YYYY:MM:DD" colon separated format
MMV: Viewer displays strange "YYYY:MM:DD" colon separated format
Status: RESOLVED DUPLICATE of bug 64014
Product: MediaWiki extensions
Classification: Unclassified
MultimediaViewer (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-06 01:30 UTC by Krinkle
Modified: 2014-10-06 08:23 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2014-10-06 01:30:30 UTC
Example:
 http://commons.wikimedia.org/wiki/File:Pelican_in_its_piety.jpg#mediaviewer/File:Pelican_in_its_piety.jpg

The viewer shows "Created: 2006:03:19 10:29:45"

I'm not sure what that format is supposed to be, but it looks like an error. Afaik no human readable standard uses that format. It certainly doesn't seem like something we'd do on purpose (based on a MediaWiki Language or Moment.js format), which is enough for it to be an error from the user's perspective.

Looking at the regular file page, it seems MediaWiki has no problem parsing this Metadata:

 Date and time of data generation
 10:29, 19 March 2006

So seems fair to expect MMV to handle this as well.

Simple Commons gadgets have never had this issue. A simple extraction of the '.exif-datetimeoriginal' node in #mw_metadata would be a step forward (instead of the imageinfo API and trying to parse it). Since that's already parsed an localised server-side. Scraping is ugly, but parsing should make it better.

The value is exposed via the imageinfo API:

http://commons.wikimedia.org/w/api.php?action=query&format=json&prop=imageinfo&titles=File%3APelican_in_its_piety%2Ejpg&iiprop=timestamp%7Cuser%7Curl%7Csize%7Cmime%7Cmediatype%7Cextmetadata&iiextmetadatafilter=DateTime%7CDateTimeOriginal%7CImageDescription%7CLicense%7CLicenseShortName%7CUsageTerms%7CLicenseUrl%7CCredit%7CArtist%7CGPSLatitude%7CGPSLongitude%7CPermission&iiextmetadatalanguage=en

    "extmetadata": {
        "DateTime": {
            "value": "2006:03:19 10:29:45",
            "source": "file-metadata",
            "hidden": ""
        },
        "ImageDescription": {
            "value": "KONICA MINOLTA DIGITAL CAMERA",
            "source": "file-metadata"
        },
        "DateTimeOriginal": {
            "value": "2006:03:19 10:29:45",
            "source": "file-metadata"
        }
    },
    "mime": "image/jpeg",
    "mediatype": "BITMAP"

Bug seems to originate from https://github.com/wikimedia/mediawiki-extensions-MultimediaViewer/blob/c86b2bba26726f2c36c340eeff7afd8d7a1c0df4/resources/mmv/ui/mmv.ui.metadataPanel.js#L672-L693 where it attempts to have Moment.js parse this format. Which it can't.

Momment.js has, however, a built-in capability to parse custom formats by passing the format as the second argument:

> moment('2006:03:19 10:29:45')
< Invalid date
> moment('2006:03:19 10:29:45', 'YYYY:M:D H:m:s')
< "Sun Mar 19 2006 10:29:45"

If this colon-separated format is how all Image metadata is stored by camera's, I'd say just parse it by telling moment.js the format.
Comment 1 Tisza Gergő 2014-10-06 08:12:46 UTC
This should be handled by CommonsMetadata. MMV trying to parse the date and falling back to displaying it as-is is reasonable behavior; there is also no reason for MMV to know about EXIF standards, using EXIF is an implementation detail of CMD.

There is another, unrelated bug here: DateTimeOriginal should be overwritten by the value in the template (EXIF data is only used as a fallback), but for some reason that does not happen.

*** This bug has been marked as a duplicate of bug 64014 ***
Comment 2 Tisza Gergő 2014-10-06 08:23:25 UTC
Opened bug 71700 about the second issue.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links