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).
Hi folks,
I am happy to let you know that we have just launched Media Viewer 0.2 on our first pilot site, MediaWiki.org, where it is now enabled by default for all users (previously, it was only available as a Beta Feature).
Media Viewer aims to improve the multimedia viewing experience on Wikipedia and Wikimedia sites, to display images in larger size and with less clutter — as well as invite more people to use our images.
We invite you to try out this new tool today, which you can do on this test page:
https://www.mediawiki.org/wiki/Lightbox_demo
Please let us know what you think on this discussion page:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer
You can learn more about this new feature here:
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
After this first pilot, we plan to enable Media Viewer by default for these next pilot sites:
• April 17 - Confirmed: Catalan, Hungarian, Korean, English Wikivoyage
• April 24 - Proposed: Czech, Estonian, Finnish, Hebrew, Polish, Romanian, Thai, Slovak, Vietnamese
Based on these first pilot results, we plan wider releases on larger wikis in the following weeks, with a goal to deploy to all wikis next month. Our release schedule will be based on new findings at each stage of deployment. If this product performs well and meets user needs, we may accelerate the deployment pace -- or we may slow it down for some sites, as needed.
More details are available on our updated Release Plan:
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
To discuss this release and review the final product together, we invite you to join our next IRC chat, on Wed. Apr. 9 at 18:00 UTC (11am PT). We also invite you to try out the tool on your own wikis, where it is available for early testing as a Beta Feature in your user preferences, as described above.
Please let us know if you have any questions, suggestions or comments about this release. And many thanks to all the community members who helped create this feature with us in recent months!
We look forward to bringing a richer multimedia experience to your community very soon.
Regards as ever,
Fabrice
on behalf of the Multimedia Team
https://www.mediawiki.org/wiki/Multimedia
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)