Including the multimedia list, since the discussion is now broader. Gergo,
Mark, I encourage you to read the backlog:
https://lists.wikimedia.org/mailman/private/ops/2014-April/thread.html#31981
On Thu, Apr 17, 2014 at 4:31 PM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org
> wrote:
> On Thu, Apr 17, 2014 at 4:13 AM, Gilles Dubuc <gilles(a)wikimedia.org>wrote:
>
>> When the user opens media viewer, but there are 4 API calls per image
>>
>
> When I tried it just now, I saw 6 queries: one to prop=imageinfo to fetch
> a number of different props, one to meta=filerepoinfo, one to
> list=imageusage, one to prop=globalusage, and two more to prop=imageinfo to
> fetch the URLs for two different sizes of the image.
>
> The first four could all be combined into one query (this is an advantage
> of the batch design of the web API over the much-touted REST model):
>
>
> https://www.mediawiki.org/w/api.php?action=query&format=json&prop=imageinfo…
>
> Being able to merge in the last two as well would be bug 54035.
>
> Also, getting really offtopic here, "guprop[]=url&guprop[]=namespace" and
> "&iunamespace[]=0&iunamespace[]=100" that I see in your original queries
> doesn't actually work; it gives the same results as if guprop and
> iunamespace are omitted entirely. The API should give a warning about that
> (filed as bug 64057).
>
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> Wikimedia Foundation
>
> _______________________________________________
> Ops mailing list
> Ops(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
>
Hi,
I understand this is not on the multimedia team priorities, but I wanted to
put under the radar the subtitle support on Wikimedia projects
I just created [[bug:64031]] to keep track of this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=subtitle
The two main features really impairing the subtitle workflow right now (in
my opinion at least) are:
* Integration with Translate extension.
Bug discussion seems to indicate not much needs to be done but the path
forward is unclear
<https://bugzilla.wikimedia.org/show_bug.cgi?id=42790>
* Amara / UniversalSubtitles integration
Amara / Universal Subtitles is an awesome tool to easily add subtitles to
videos.
As part of the 2011 (?) multimedia Beta, we used to have it integrated on
Wikimedia Commons, but not anymore (not sure when that was discontinued).
Where did it go? What would it take to have it back?
<https://bugzilla.wikimedia.org/show_bug.cgi?id=62699>
I hope this is in scope of this list :)
Thanks,
--
Jean-Frédéric
Hi folks,
We’d love to hear what you think of Media Viewer, our new multimedia browser, as we get ready to release it more widely in coming weeks.
Is Media Viewer useful to you? What do you like most? least? How can we improve this tool? Are there any critical improvements we should consider before launch?
Here are three ways you can share your feedback about this new viewing experience:
1. Join our IRC chat
We’re hosting a live IRC chat in a few hours, this Wed. Apr. 9 at 18:00 UTC on #wikimedia-office.
All are welcome! Drop by to meet the team, share your comments, ask questions about this release, or make suggestions for improvement.
https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
2. Discuss this tool
Meet other beta users from around the world on our Media Viewer discussion page. Here, we talk about new features, bugs and ideas with our community.
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
3. Take a quick survey
Can you tell us how Media Viewer works for you? It only takes a minute and means a lot to us.
https://www.surveymonkey.com/s/media-viewer-1?c=email
Hope to hear from you on one of these channels. Your feedback will help us improve the tool and launch it more smoothly.
Speak to you soon,
Fabrice — for the Multimedia Team
P.S.: If you haven’t tried Media Viewer yet, visit this test page on MediaWiki.org:
https://www.mediawiki.org/wiki/Lightbox_demo
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi,
Since mediawiki.org finally moved to '21, I was able to run the performance
tests against production again. We now have a figure for how bad the cold
cache experience can be. On an average-sized browser window, the cold cache
image load in media viewer takes around 200% of the time it takes for the
image to appear on the File: page with a warm cache*. And it takes around
230% of the time for a large browser window. We're talking seconds of
difference, that's a long time to wait.
When we first built mmv.bootstrap (the on-demand loading of JS), we didn't
have the click catcher (mmv.head). Now that we do, I think we can afford to
sacrifice some user bandwidth and just load Media Viewer's JS with the
async attribute (which means it wouldn't block page rendering). And
mmv.head would take care of catching and replaying clicks that happened
before Media Viewer's JS was loaded.
Doing that means we could get rid of mmv.bootstrap entirely, increase the
cold cache performance (chances are, the thumbnails on a given page will
take longer to load than Media Viewer's JS and CSS) and simplify our code.
Any objections to doing this?
**the reason why we're not comparing figures with the File: page on a cold
cache is that it's an unfair comparison: all of mediawiki's JS and CSS
would be cold in that case, whereas for Media Viewer it's only Media
Viewer's JS and CSS that is cold.*
Are retina screens being handled by MMV in any sort of way ?
I don't have one of those machines, so I have trouble verifying. (Brion has one right ?)
DJ
Hi guys,
We are trying to assess how many images are stored locally on Wikimedia sites, rather than hosted on Commons. We also want to better understand what templates they are using for their metadata.
Does anyone know where we could find reliable statistics and links for these non-Commons files?
We would like to check how well they work with Media Viewer, as well as get a sense of scope.
If they use the same templates and data structure as Commons, they should display well in Media Viewer. But if they use different templates, these would need to be modified for their meta-data to appear in Media Viewer.
Last time we checked, there were over 800k image files hosted on English Wikipedia alone, so this could be a significant number, which may require some advance work to get them ready for Media Viewer.
Gergo is preparing a document to address the template issue, which he can share with us when it’s ready.
Thanks,
Fabrice
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
On Wed, Apr 9, 2014 at 3:03 AM, Gilles Dubuc <gilles(a)wikimedia.org> wrote:
> Since mediawiki.org finally moved to '21, I was able to run the
> performance tests against production again. We now have a figure for how
> bad the cold cache experience can be. On an average-sized browser window,
> the cold cache image load in media viewer takes around 200% of the time it
> takes for the image to appear on the File: page with a warm cache*. And it
> takes around 230% of the time for a large browser window. We're talking
> seconds of difference, that's a long time to wait.
>
(...)
> **the reason why we're not comparing figures with the File: page on a cold
> cache is that it's an unfair comparison: all of mediawiki's JS and CSS
> would be cold in that case, whereas for Media Viewer it's only Media
> Viewer's JS and CSS that is cold.*
On the other hand, a cold cache should happen infrequently (about once a
week while MultiediaViewer is under active development, about once a month
after that). Giving a bad first impression is unfortunate, but the user
experience is not impacted that much beyond that, I think.
When we first built mmv.bootstrap (the on-demand loading of JS), we didn't
> have the click catcher (mmv.head). Now that we do, I think we can afford to
> sacrifice some user bandwidth and just load Media Viewer's JS with the
> async attribute (which means it wouldn't block page rendering). And
> mmv.head would take care of catching and replaying clicks that happened
> before Media Viewer's JS was loaded.
>
> Doing that means we could get rid of mmv.bootstrap entirely, increase the
> cold cache performance (chances are, the thumbnails on a given page will
> take longer to load than Media Viewer's JS and CSS) and simplify our code.
>
> Any objections to doing this?
>
To clarify, this is the current state:
* mmv.head (~2K*) is top-loaded for every user on every page that contains
images, to delay image thumbnail clicks until mmb.bootstrap is loaded
* mmv.bootstrap (~35K with all dependencies) is bottom-loaded for every
user on every page that contains images; it handles entry points (URL hash
changes, image clicks) and loads the full application when the user
requests it
* the full application (around 500K) is only loaded when it is actually
needed
This is what you propose:
* mmv.head is still top-loaded for everyone
* everything else is bottom-loaded for everyone, all the time
Do I understand it right?
If so, I think we should consider this again when MediaViewer is enabled by
default. Right now mmv.head and mmv.bootstrap is loaded for everyone, even
if they did not opt in to the beta feature (or, on a pilot wiki, explicitly
disabled the tool), so that we can handle URL hashes (and URLs shared by
people who have MediaViewer enabled do not break for everyone else). This
is not a big deal when we are just talking about a few kilobytes, but
loading all of MultimediaViewer all the time for everyone, even if 99% will
never use it, is not worth the performance win, IMO.
Once it is enabled for everyone, we should get some stats on what fraction
of the userbase never uses it, and if it is not too large, then we can just
load it for everyone (since it would be loaded for almost everyone with the
current setup as well, just with a timing that's more inconvenient for the
user).
* the sizes are unminified, ungzipped, which is not very useful, but that's
what I had at hand.
Hello friends of multimedia … and greetings from Bali!
I’m on vacation here through the end of the week, but just took a break from my yoga retreat to submit these session proposals for Wikimania 2014, since the deadline is today:
* Multimedia_Overview
Presentation - 30 mins.
https://wikimania2014.wikimedia.org/wiki/Submissions/Multimedia_Overview
* Multimedia Roundtable
Workshop/Discussion - 150 mins.
https://wikimania2014.wikimedia.org/wiki/Submissions/Multimedia_Roundtable
The first proposal is intended for folks who just want a quick update on what we’re working on. The second one is going to be a more interactive, in-depth brainstorming session to help plan our next steps together, much as we did last year in Hong Kong:
https://meta.wikimedia.org/wiki/Roundtables/Roundtable_3
If you plan to go to Wikimania this year and you are interested in either of these sessions, please sign up at the bottom of the submission pages to let the organizers know of your interest.
Namaste,
Fabrice
P.S.: I will not respond to emails on this account until I return to work next Monday. But in my absence, Gilles Dubuc and others on the multimedia team can address any questions you might have about these sessions, as well as make any tweaks to the submissions, as needed.
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Hi team,
one piece of feedback from Aaron's recent retrospective (not sure if we
have a public link for it?) that I felt was a very good advice was that we
should track the number and type of incidents (an incident being when
something maintained by the multimedia team breaks in production) so that
we can get an overview of how good our QA/CI practices are and what needs
to be improved.
With that in mind I created this page:
https://www.mediawiki.org/wiki/Multimedia/Incidents
Please expand it whenever something comes up (or even with older events if
you still remember them).
