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>
Trevor Parscal | 30 Aug 01:36 2014

OOjs UI Mixin Changes

Mixins in OOjs UI have always had, shall we say, "strange" names. Popuppable is my personal favorite, but the most strange thing about them has always been the lack of correlation between their name and what it is that they actually do. Furthermore, Alex came across a situation where the convention of providing an element to a mixin at construction is not always possible.

I've written a patch[1][2][3] which does the following:
  • Mixins are now named according to what they do[2], using the "ed" suffix if the mixin adds/manages attributes, "able" if it adds/manages behavior and no suffix if it adds content.
  • Mixins no longer take a required element argument, but do still allow the element to be passed through the config options
  • Mixins use a set{Type}Element method to set and even change the element being targeted by the mixin - this is called in the constructor with an overridable default, but can also be called again and again
Attribute and behavior mixins always operate on this.$element by deafault. Content mixins always generate an element to operate on by default. Again, in both cases the element being initially targeted can be configured using the config object.

This division was made specifically to reduce or eliminate the need for using this.$( '<{tagName}' ); when invoking the mixin constructor, and instead doing what was being done most of the time automatically.

The rename will hopefully not cause too much confusion. It's important to note that both the JavaScript and CSS classes have been updated.

Roan is reviewing the patches and they will probably be merged shortly. If you know of any code that may be affected by this change but has not been considered in the patches mentioned, please let me know.

- Trevor

[4] Table of classes that have been renamed

ButtonedElement ButtonElement
IconedElement IconElement
IndicatedElement IndicatorElement
LabeledElement LabelElement
PopuppableElement PopupElement
FlaggableElement FlaggedElement
Multimedia mailing list
Multimedia <at>
Fabrice Florin | 28 Aug 23:11 2014

Join the Media Viewer Consultation

Hello friends of multimedia,

We would like to invite you to join a global community consultation about Media Viewer.

Please take a moment to join the discussion and add your suggestions for improvement here:

The goal of this consultation is to review the status of this project and identify any critical issues that still need to be addressed -- so we can plan our next steps based on your feedback. 

The consultation will be open until September 7th. If agreed upon critical issues cannot be resolved in the near term, the Wikimedia Foundation will temporarily move the feature back into opt-in beta globally.

Here’s our latest Media Viewer Improvements plan, where our team will post regular updates on our planned development tasks:

Note that the proposed tasks on that page are still preliminary, and may be adjusted based on community feedback and ongoing user studies.

We look forward to hearing from you on the consultation page.

Regards as ever,



Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
svetlana | 25 Aug 07:02 2014

Fwd: Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Forwarding to a relevant list -- I hope this is useful feedback to the Multimedia team itself


----- Original message -----
From: John Mark Vandenberg <jayvdb <at>>
To: Wikimedia Mailing List <wikimedia-l <at>>
Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments
Date: Mon, 25 Aug 2014 14:37:19 +1000

On Mon, Aug 25, 2014 at 2:07 PM, Marc A. Pelletier <marc <at>> wrote:
> On 08/24/2014 11:19 PM, Pine W wrote:
>> I have
>> heard people say "don't force an interface change on me that I don't think
>> is an improvement."
> I do not recall a recent interface change deployment that wasn't
> accompanied with, at the very least, some method of opting out.  Did I
> miss one?

Did you try opting out of MediaViewer on the mobile version?

I think the response that I received confirmed it wasnt possible.

Per-user opt-out aside, the WMF was still forcing an interface change
onto the community at large.  With VE, the WMF needed the community to
add TemplateData to all templates to help the newbies who were using
VE; with MV, the WMF needed the community to 'tag' images which
shouldnt be shown in the MV, and there is an ongoing need for the
community to 'fix' the image page syntax in order for the information
to display correctly to the end users in MV.

In both cases, significant amounts of volunteer time is required to
avoid a bad user experience.
WMF needs 'buy-in' for that, if it wants volunteers to be happy
volunteers while doing mundane work to make the new software suck

John Vandenberg

Wikimedia-l mailing list, guidelines at:
Wikimedia-l <at>
Unsubscribe:, <mailto:wikimedia-l-request <at>>

Multimedia mailing list
Multimedia <at>
Erik Moeller | 23 Aug 19:46 2014

Inspect CommonsMetadata easily

FYI - User:TheDJ has made a very handy tool that will let you see the machine-readable data (per COM:MRD) for a given file on the File: page. This helps ensure that any automated re-use can be done in a manner that's license compliant and consistent with authors' wishes. To give it a spin, import this guy into your common.js:

This should definitely help leading into the systematic structured data efforts. Still early days and would make a nice gadget down the line :)

Multimedia mailing list
Multimedia <at>
Fabrice Florin | 22 Aug 10:48 2014

Structured Data on Commons


We invite you to join a discussion about Structured Data on Commons, to help us plan our next steps for this project.

The Structured Data initiative proposes to store and retrieve information for media files in machine-readable data on Wikimedia Commons, using Wikidata tools and practices, as described on our new project page (1).

The purpose of this project is to make it easier for users to read and write file information, and to enable developers to build better tools to view, search, edit, curate and use media files. To that end, we propose to investigate this opportunity together through community discussions and small experiments. If these initial tests are successful, we would develop new tools and practices for structured data, then work with our communities to gradually migrate unstructured data into a machine-readable format over time.

The Multimedia team and the Wikidata team are starting to plan this project together, in collaboration with many community volunteers active on Wikimedia Commons and other wikis. We had a truly inspiring roundtable discussion about Structured Data at Wikimania a few weeks ago, to define a first proposal together (2). 

We would now like to extend this discussion to include more community members that might benefit from this initiative. Please take a moment to read the project overview on Commons, then let us know what you think, by answering some of the questions on its talk page (3).

We also invite you to join a Structured Data Q&A on Wednesday September 3 at 19:00 UTC, so we can discuss some of the details live in this IRC office hours chat. Please RSVP if you plan to attend (4).

Lastly, we propose to form small workgroups to investigate workflows, data structure, research, platform, features, migration and other open issues. If you are interested in contributing to one of these workgroups, we invite you to sign up on directly on our hub page (5) -- and help start a sub-page for your workgroup.

We look forward to some productive discussions with you in coming weeks. In previous roundtables, many of you told us this is the most important contribution that our team can make to support multimedia in coming years. We heard you loud and clear and are happy to devote more resources to bring it to life, with your help.

We are honored to be working with the Wikidata team and talented community members like you to take on this challenge, improve our infrastructure and provide a better experience for all our users.


Fabrice — for the Structured Data team

(1) Structured Data Hub on Commons:

(2) Structured Data Slides:

(3) Structured Data Talk Page:

(4) Structured Data Q&A (IRC chat on Sep. 3):

(5) Structured Data Workgroups:


Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
Fabrice Florin | 21 Aug 02:24 2014

Multimedia Update

Hello friends of Multimedia,

Time for another update about our multimedia project. We’re sorry about the radio silence in recent weeks, as many of us were tied up at Wikimania and/or traveling.

Here are some highlights of what we’ve been working on this month:

1. Media Viewer Improvements
We are now working to improve Media Viewer in coming weeks, to address editor concerns while making it even more useful for readers — our main target users for this product. Here are some of the improvements we are planning to test and develop for the next version:
* a much more visible link to the File: page;
* an even easier way to disable the tool;
* a caption or description right below the image
* remove additional metadata below the image, directing users to the File: page instead.

As described in our improvements plan (1), these features are now being prototyped and will be carefully tested with target users in coming days, so we can validate their effectiveness before developing and deploying them in September. You can see some of our thinking in this presentation we discussed with community members at Wikimania in London  (2) -- with positive responses from many experienced users. We’ll keep you posted on what we learn from this research in coming days, based on our latest prototype (3). Please contact us if you are interested in testing the prototype, with the understanding that we are now optimizing it for casual users, not power users. 

2. Community Discussions
While Media Viewer has generally been well received on most wikis, you’ve probably heard by now that it was the subject of three separate Requests for Comments on the English and German Wikipedias, as well as on Wikimedia Commons. 

The Wikimedia Foundation has now responded to all three RfCs, as briefly summarized below. We understand that a majority of editors participating in these RfCs would prefer that Media Viewer be disabled by default for all users. Yet many of those editors have also correctly pointed out that Media Viewer is primarily aimed at readers — and the feedback we have collected so far shows that many readers find this tool useful, across our projects. We also note that if Media Viewer were to be disabled by default, it would be very difficult for those readers to re-discover it and re-enable it. So it seems important to keep it enabled for logged-out users, instead of preventing them from using it, if they find valuable. And while we recognize that enabling Media Viewer by default can be inconvenient for logged-in editors, it’s also easy to disable -- either within the tool itself, or in their preferences -- and we plan to make it even easier to opt out in the next version. For software tools like these, our view is that we should let individual users decide for themselves if they want to keep new features enabled. 

For these reasons, the foundation respectfully declined to disable Media Viewer by default for either logged-in or logged-out users on the English and German Wikipedias at this time. On Wikimedia Commons, however, the tool has just been disabled for logged in users by default, as a special exception due to that project's primary focus on media curation. Each community has responded in different ways to the foundation’s statements. In one case, our decision to leave Media Viewer enabled by default led to a conflict escalation between the foundation and some German community members, which we deeply regret. In coming weeks, we will exert our best efforts to resolve these issues in a variety of ways, from improving Media Viewer itself (see above), to improving the process by which new features are developed, tested and released (see below). 

3. Working Together
As our executive director Lila Tretikov stated on her talk page (3), the foundation is committed to working with the community towards a constructive resolution of this and any future disputes. We are now reviewing our current development processes and exploring new approaches to allow for feedback at more critical and relevant junctures. With that in mind, we invite you to help brainstorm ideas that might improve community engagement for future product rollouts, on this special page (4). I will also be going to Germany in about a month to discuss some of these issues in person with community members, whom I really look forward to meeting face-to-face.

4. Wikimania Update
Most of our multimedia team was present at Wikimania in London, where we hosted 7 different roundtable discussions and sessions, which we found extremely productive. Topics ranged the gamut from the Structured Data to Upload Wizard, Media Viewer, Video, Community Engagement — and yes, even Kindness. We really enjoyed our many constructive conversations with hundreds of community members, who worked with us as partners to improve our plans and products in a variety of useful ways. We’re very grateful for these special collaborations, which keep getting stronger year after year. In coming days, we will share what we learned together in some of these sessions. For now, you can check each session's slides and notes, which are linked on this overview page (5). You might also enjoy some of my favorite photos from this exceptional gathering (6), as well as the latest installment in my ongoing series of community ideas on how to improve Wikipedia (7). Finally, those of you who read German might appreciate User:Ziko’s excellent article for the Kurier on our in-depth conversation in London (9). 

Overall, the wonderful collaborations we’ve enjoyed with many of you at Wikimania are a great example of what is possible when we all work together in good faith and with mutual respect for each other. 

Thanks to everyone who made this inspiring event possible!

I am sorry about the length of this message, but we had a lot to catch up on: I wanted to cover some of the recent events, so we can move forward with a shared understanding of how we got there, where we’re going, and how we can improve things together.

We all look forward to more collaborations with you on Structured Data, Upload Wizard, Video and other projects looming on the horizon — above and beyond Media Viewer. :)

To be continued …

Fabrice — for the Multimedia Team.



Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
Andre Klapper | 20 Aug 16:52 2014

UploadWizard bug triage?


I think mtraceur pinged me on IRC a while ago, proposing an UploadWizard
bug triage. If I remembered correctly:

Any specific aspects or topic in mind? Some general "let's retry random
reports if they are still valid"? Or more looking at priorities of

If retesting reports: Would retesting take place on , I
assume that the broken first image and the missing templates exposed in
the summary are "alright"? (Asking because this might confuse potential
volunteers trying to reproduce issues there.)

Severity x priority table of open tickets (might come handy):


[Please CC me on replies; I'm not subscribed to multimedia <at> ]

Andre Klapper | Wikimedia Bugwrangler

Multimedia mailing list
Multimedia <at>
Gilles Dubuc | 13 Aug 10:36 2014

Image sizes on the file page

Currently the file page provides a set of different image sizes for the user to directly access. These sizes are usually width-based. However, for tall images they are height-based. The thumbnail urls, which are used to generate them pass only a width.

What this means is that tall images end up with arbitrary thumbnail widths that don't follow the set of sizes meant for the file page. The end result from an ops perspective is that we end up with very diverse widths for thumbnails. Not a problem in itself, but the exposure of these random-ish widths on the file page means that we can't set a different caching policy for non-standard widths without affecting the images linked from the file page.

I see two solutions to this problem, if we want to introduce different caching tiers for thumbnail sizes that come from mediawiki and thumbnail sizes that were requested by other things.

The first one would be to always keep the size progression on the file page width-bound, even for soft-rotated images. The first drawback of this is that for very skinny/very wide images the file size progression between the sizes could become steep. The second drawback is that we'd often offer less size options, because they'd be based on the smallest dimension.

The second option would be to change the syntax of the thumbnail urls in order to allow height constraint. This is a pretty scary change.

If we don't do anything, it simply means that we'll have to apply the same caching policy to every size smaller than 1280. We could already save quite a bit of storage space by evicting non-standard sizes larger than that, but sizes lower than 1280 would have to stay the way they are now.

Multimedia mailing list
Multimedia <at>
Maarten Dammers | 7 Aug 15:52 2014

Rijksmuseum website

Hi everyone,

I was talking with several people here at Wikimania about the 
Rijksmuseum website. Take for example . I like the design a 
lot. Maybe a good inspiration for future designs?


Multimedia mailing list
Multimedia <at>
Fabrice Florin | 6 Aug 09:22 2014

Multimedia events this week at Wikimania

Hello, friends of multimedia!

We're hosting some cool multimedia events this week at Wikimania in London: 

We are also hosting a special afternoon tea on Friday at 17:00, for those of you who have worked closely with us in some of our recent releases:

Be sure to sign up and join us for any of these events, if you're in town!

Speak to you soon,



Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>