Pau Giner | 17 Sep 14:14 2014

Captions, descriptions, and duplication

Hi all,

While adding details on story #589 about showing the caption above the fold in Media Viewer, I recalled that we were considering not showing the file description below the fold for files that have both a caption and a description. I wanted to confirm if that is the case, and the changes it will imply.

I created story #895 to capture required changes if we remove the below the fold description. Basically it reorganises a little bit the authorship information so that is can expand using the room the description used and avoids just having an empty area below the fold.

The rationale for removing the description below the fold was that for files that have both caption and description they tend to be redundant most of the time. I did a quick exploration by picking some random vital articles and going through 62 images:
  • 46% of the images lack description or it was not shown in Media Viewer
  • From the rest of the files where both caption and description:
    • 58% (26% of total) provide redundant information or the description didn't add additional details (example).
    • 44% (20% of total) show more details on the description or complementary info to the caption (example).
I'm not sure how representative this is compared to all our files (any data on the subject is welcome), but taking into account that the file description can be accessed through the "more details" button which we plan to make more prominent, I'm ok with removing it if we don't found stronger evidence of its need.

Should that be made as part of the changes of #589? I don't know, I created card #895 as a separate card so that it can be done after  #589 or at the same time, as it makes more sense according to development efforts.

Any thoughts?


Pau Giner
Interaction Designer
Wikimedia Foundation
Multimedia mailing list
Multimedia <at>
Gergo Tisza | 15 Sep 02:30 2014

PayPal video player

PayPal published an opensource HTML5 video player a couple days ago, with focus on accessibility. Seems pretty neat at a glance.

Multimedia mailing list
Multimedia <at>
Fabrice Florin | 14 Sep 04:35 2014

Media Viewer Tasks for next week

Hi guys,

I am getting ready to turn off my work email until I return from vacation on Sep. 24.

Before I go, here’s my recommended to-do list for next week, with a focus on Media Viewer improvements. 

It is based in part on this updated improvements plan:

I considered emailing each of you individually about specific tasks on this list, but a single message to the team may be more helpful, so we’re all on the same page.

* Lead Wednesday's sprint planning meeting 
* Update the Etherpad, Mingle site and Improvements page
* Deploy and monitor 'Pre-render thumbnails on backend’ (#301)
* Investigate better performance metrics solution for Media Viewer (#881)
* Run "versus" test on a dedicated labs instance (#884)

* Complete and deploy ‘More Details’ button with project icon (#830, 873)
* Complete and deploy Download and Share buttons (#841, 834)
* Develop Disable / Enable tools (#836, 719, 870) 
* Show clearer indication of authorship (#837)
* Work closely with Pau on all design questions (via IRC in your AM, then email in the PM)

* Disable MediaViewer for logged-in Commons users (#822)
* Help with back-end on Disable / Enable tools, as needed (#836, 719, 870) 
* Update 'File: Page vs. MMV' performance dashboard with improved user data (#880)
* Performance histogram for MediaViewer and File page (#815)
* Help with attribution/licensing improvements for metadata cleanup effort

* Update specs with all assets for Disable / Enable tools (#836, 719, 870) 
* Finalize design for Caption above the fold + how to expand/collapse it (#589) 
* Propose a design for how to access ‘Help’ or ‘About’ pages from Media Viewer
* Join our IRC MM channel at the end of your day (to work more closely with Mark)

* Respond to new comments on consultation or MV talk pages 
* Thank contributors to consultation whose suggestions made it to the list
* Archive old comments on Media Viewer talk page

* Write findings from Disable / Enable user testing with Pau
* Add a few more screenshots on August report (with credits)
* Post wiki report on July user studies, for transparency reasons

See Current Cycle wall for more details:

I hope this outline is helpful. There may be other priority tasks that are not listed here, but I wanted to give you a sense of action items that seem important for the next 2 weeks, from my standpoint.

In my absence, Erik and Howie will tag team to provide product input on all this. Erik will join next Wednesday’s sprint planning meeting and can help test important features for deployment.

I look forward to seeing you all the following Wednesday, Sep. 24, at the 9am PT weekly meeting. I will not check work email during that time. If you need to reach me urgently, my personal email is .

Good luck and speak to you soon!



Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
Chris McMahon | 12 Sep 19:03 2014

MMV browser tests for IE versions

We created a set of these, you can see them at: 

In the near future I would like to refine exactly what is required for these builds as regards

* browser
* version
* OS (if applicable)
* target environment (beta, test2, mw.o)

as well as whatever additional feature coverage we might provide. 


Multimedia mailing list
Multimedia <at>
Fabrice Florin | 12 Sep 05:01 2014

Media Viewer Consultation Results

Thanks to everyone who participated in the recent Media Viewer Consultation! 

Our multimedia team appreciates the many constructive suggestions to improve the viewing experience for
readers and casual editors on Wikimedia projects. We reviewed about 130 community suggestions and
prioritized a number of important development tasks for the next release of this feature. Those
prioritized tasks have now been added to the improvements list on the consultation page. (1)

We have already started development of the most critical improvements: 'must-have’ features that this
consultation helped identify and that have been validated through user testing — see research
findings (2) and design prototype (3). We plan to complete all these 'must have' improvements by the end of
October and will deploy them incrementally, starting this week. For more details, see our improvement
plan (4) and development tasks for the next 6 weeks (5).

As we release these improvements, we will post regular updates on the Media Viewer talk page (6). We invite
you to review these improvements and share your feedback. 

The foundation is also launching a file metadata cleanup drive (7) to add machine-readable attributions
and licenses on files lack them. This will lay the groundwork for the structured data partnership (8) with
the Wikidata team, to enable better search and re-use of media in our projects. We encourage everyone to
join these efforts.

This community consultation was very productive for us and we look forward to more collaborations in the

Thanks again to all our gracious contributors. We consider ourselves lucky to have so many great community partners.












Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
Oliver Keyes | 9 Sep 17:53 2014

Odd requestlog entry

URL runs "", user_agent is "MediaWiki/1.24wmf19". Is this you guys?

Oliver Keyes
Research Analyst
Wikimedia Foundation
Multimedia mailing list
Multimedia <at>
Guillaume Paumier | 4 Sep 20:05 2014

Making UploadWizard and Structured Data actual engineering activities on


As most of you know, we document WMF engineering activities on using "activity pages", which is just a fancy word for
pages that have an infobox. We can then list the activities in many
places, like the Wikimedia Engineering portal ( ) and the status
dashboard (

Most of the activities are about a particular project, like
"Phabricator migration" or "Flow". Multimedia is a bit awkward because
it's about a team rather than the projects you guys work on.

It might have made sense previously (for example if the team was
touching a lot of different pieces of Multimedia) but my understanding
from the Wikimania workshops is that the Multimedia team plans to
mostly focus on two main projects this fiscal year: UploadWizard and
Structured Data.

Therefore, I'd like to recommend that we make those two projects
actual "activities", with a dedicated infobox and status updates.
Other, smaller multimedia-related bits like MediaViewer could still be
in the catch-all "Multimedia" activity.

This wouldn't change anything for most of you; the only visible
difference would be that you would report on UploadWizard and
Structured Data on a different page. It would be more consistent with
the rest of WMF engineering, and it would be easier for the rest of
the community to follow your work on each project.

Unless there are strong objections to this proposal, I'm happy to add
the infoboxes myself, but I wanted to ask here first :) Let me know if
you have any questions.


Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
Jean-Frédéric | 4 Sep 13:49 2014

Re: [Commons-l] Hashing Wikimedia Commons

> The first three we can get from pretty much either API, or extract directly from
> a dump file. The latter is eluding us though, for two reasons. One is that a
> file, like 30C3_Commons_Machinery_2.jpg, is actually in the /b/ba/ directory -
> but where this /b/ba/ comes from (a hash?) is unclear to us now, and it's not
> something we find in the dumps - though we can get it from one of the APIs.

Yes, /b/ba ist based on the first two digits of the MD5 hash of the title:

md5( "30C3_Commons_Machinery_2.jpg" ) -> ba253c78d894a80788940a3ca765debb

But this is "arcane knowledge" which nobody should really rely on. The canonical
way would be to use

Which generates a redirect to

To get a thumbnail, you can directly manipulate that URL, by inserting "thumb/"
and the desired size in the correct location (maybe Special:Redirect can do that
for you, but I do not know how):

If I am not mistaken you can use thumb.php to get the needed thumb?

Hope that helps,
Multimedia mailing list
Multimedia <at>
Jared Zimmerman | 3 Sep 20:27 2014

Re: instrumentation of current (old) upload wizard

thanks for the list email, I must have typed it wrong and it bounced, so I emailed you guys directly. 

Things I'm interested in…

- Abandon rate (and where a user is in the process)
- browse button vs drag and drop usage
- frequency that the page returns an error, and what that error is (we still don't have all required fields marked as required)
- frequency of users expanding/adding additional information beyond the defaults (extra languages, additional categories)

Jared Zimmerman  \\  Director of User Experience \\ Wikimedia Foundation               
M +1 415 609 4043 \\   <at> jaredzimmerman

On Wed, Sep 3, 2014 at 11:19 AM, Mark Holmquist <> wrote:
On Wed, Sep 03, 2014 at 10:49:54AM -0700, Jared Zimmerman wrote:
> I this done? anything interesting to report? if not done, when is is
> scheduled for?

Hi, Jared. It would be super if you could contact the Multimedia team via
our mailing list,, it's much more reliable.

UW is only partially EventLogging'd right now, but we have a few in-progress
patches that should add more data.

Is there anything in particular that you'd like to know?

Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
Gilles Dubuc | 3 Sep 07:33 2014

Fwd: [Engineering] [BREAKING CHANGE] Deprecated JavaScript methods removed in MediaWiki 1.25

Task filed for UW and MediaViewer:

---------- Forwarded message ----------
From: Timo Tijhof <>
Date: Wed, Sep 3, 2014 at 2:41 AM
Subject: [Engineering] [BREAKING CHANGE] Deprecated JavaScript methods removed in MediaWiki 1.25
To: engineering Wikimedia List <>

* Several deprecated methods in MediaWiki's JavaScript modules will be removed
in a few weeks' time.
* Check your code to ensure it won't break with these changes, and update it
if needed.
* Check and fix any gadgets or scripts you or your wikis rely upon, to prevent

As part of the regular update cycle, a number of deprecated methods in our
JavaScript modules will be removed in the MediaWiki 1.25 release. This is an
announcement to give people notice they should update any extensions, gadgets
and scripts they have written, maintain, or rely upon.

Usually we don't give this much attention to removal of deprecated methods,
but due to this being our first proper development cycle for our front-end
code base, I want to make sure this reaches everyone. You're likely not yet in
the habit of updating front-end code between MediaWiki releases.

Deprecated methods to be removed in MediaWiki 1.25:

* Remove method. [1]
Deprecated since MediaWiki 1.20. Use mw.user.getName() instead.

* Remove mw.user.anon() method. [1]
Deprecated since MediaWiki 1.20): Use mw.user.isAnon() instead.

* Remove mediawiki.api methods' "ok" and "err" callback parameters. [2]
Deprecated since MediaWiki 1.23. Use the returned Promise interface instead.

* Remove mediawiki.api.category "async" parameter. [2]
Deprecated since MediaWiki 1.23. The ability to override $.ajax() to not be
asynchronous has been removed. The default (asynchronous) behaviour remains.
Use the Promise interface to retreive the fetched data from the API.

* Remove jquery.json module.
Deprecated since MediaWiki 1.24. [3] Use standardised JSON.stringify and
JSON.parse methods. And depend on the "json" module to ensure a polyfill is
lazy-loaded for cross-browser support.

## Timeline

These removals will land in MediaWiki 1.25alpha in early October 2014, being
deployed to Wikimedia wikis in October 2014 (probably 1.25wmf2 or 1.25wmf3).

The MediaWiki 1.25.0 stable release is expected to come out around April

You should make sure that your code is updated before your wiki upgrades to
MediaWiki 1.25. If you know code you rely upon will be affected but don't know
how to fix it, please check with your wiki's community for local experts. If
none of them can help, you can ask for assistance on the the
wikitech-ambassadors mailing list. [5]

## Reminders

In case you've missed the previous announcements:

* The migration period for jQuery core is still on-going and is also scheduled
for MediaWiki 1.25. [4] More about that in the mail from June 2014:

* Learn about deprecation notices and how you can see them in your browser.


– Timo

PS: You can get a sense of the progress on our different migrations, past and
present, via these graphs:

PS2: This will soon be sent to wikitech-l, mediawiki-l and wikitech-ambassadors as well.
Engineering mailing list

Multimedia mailing list
Multimedia <at>
Gilles Dubuc | 1 Sep 09:02 2014

Prerendering thumbnails at upload time

Hi opsen,

I'm currently working on this changeset: whose goal is to pre-render commonly used thumbnail sizes at upload time, in order to avoid the delay experienced by users who are the first to view a particular image at a given size (particularly in media viewer).

So far I've implemented it as a job (in the job queue sense of the term). Which implies that the server(s) picking up this job type would need to have the whole stack of image processing software installed on them. The idea being that we could the resources for this prerendering separately from the existing pool of on-demand image scalers. Does this approach make sense from an Ops perspective? Basically having one or more servers with the same software as image scalers installed on them, configured as job runners for that particular job type.

The alternative is that the job would cURL the thumbnail urls to hit the image scalers. I'm not sure that this is a desirable network path, it might not be the most future-proof thing to expect job runners to be able to hit our public-facing URLs. Not to mention this makes it a very WMF-specific solution, whereas the job type approach is more generic. Maybe there's a better way for a job runner to make the image scalers do something, though. That alternative approach of hitting thumbnail urls would imply the job running on the regular pool of job runners. And it would mean that we probably wouldn't be able to tell apart the resource usage of the prerendering compared to the regular on-demand thumbnailing that's happening at the moment.
Multimedia mailing list
Multimedia <at>