Several people complained that "Learn more on Wikimedia Commons"
is not clear: it can be interpreted as a link to the Commons
main page, the text does not suggest that the link will be related
to this specific file. The new wording tries to address this.
Change-Id: Ia605cc30c4ca57598f7cebdde60061800a10b6e7
This uses best-effort logging (like most other links do), not the
blocking call that's used by the other file page link, since
analytics folks had severe misgivings about that.
Change-Id: I35204420c834fa4fce3dcf81403cb78b92811caf
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/726
Instead of setting the parent's height as max height of the
<img> element, find the first parent which has a non-automatic
height (that would be .mw-mmv-image-wrapper).
With the old structure, the height of the parent element could
be determined by the height of the image, which would then be
written back into the max-height of the image, messing up the
aspect ratio. I did not see this in the wild, but it was easy
to reproduce by changing the timing of the resize handler (in
particular, I tried to call the resize handler before loading
the new resolution, to make the UI more responsive, and ran
into this problem). This cannot happen anymore now.
This also fix a bug on some browsers (IE 10, maybe iOS Safari)
where the size of the image could be slightly larger than the
available space, and the bottom of the image was obscured by
the metadata panel. I am still not sure how exactly that
happened, but it was related to the <img> parents with automatic
heights having incorrect height. After making sure the <img>
has a max-height derived from an element with non-automatic
height, I cannot reproduce the bug on IE 10 anymore.
Change-Id: I193aefc42e6d6072717643659a9e4c0c8b7c7e93
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/698
Bug: 66244
This got swapped up - created is the one which is parsed from a
template and can have all kinds of weird values. Uploaded comes from
MediaWiki and is always a proper localized date.
Change-Id: I12f60770f9841c9b379280cdf2190275fa04e5cb
This includes images where the <img> element has that class
(achievable with [[File:Foo.png|class=noviewer]]) and also those
where some parent element has it.
Change-Id: I666be026828ea9ecb6e8c93d3f5ad1e3c190f81e
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/511
Chevron icons for the new design of the chevron.
Beware that the active version of the chevron is white since it is assuming
it will have a blue background.
Change-Id: I3d8fa040bfecc219a735565d5ebee8e283691bee
The current message is:
Close this tool. Or press 'Esc' to exit
It has several problems:
* No full stop.
* Very long.
* Strange grammar: beginning a sentence with "Or" is unusual.
I simply put the Esc in parentheses, which is a common practice
with keyboard shortcuts.
Change-Id: Ib79ba8020885200ae2aaf7830ab337936c436752
Mark pointed out that using localized namespace names would cause
problems when users try to reuse images across wikis with different
content language. Reverting for now.
This reverts commit 59b8e5c82a.
Bug: 64710
Change-Id: I4b8b46871a1c80bce20e4017aa8adcfe3041bb4a
Previously 'up' brought the panel up, and 'down' brought it down,
which might conflict with expectations on scrolling. Up/down keys
now move the metadata panel to the opposite state, no matter what
the current state was.
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/697
Change-Id: I53079d81042afb86354bf44e9dfd662adf1576cb
Based on enwiki feedback by Jonesey95: "Created on…" does not work
well when the date is not a day (and we have dates like "1992" or
"circa 1400"). "Created: …" works reasonably well for everything.
Same for "Uploaded on…".
Change-Id: I46b51880be2151a467ccb90a76dde6efc5991cd5
